Re: Binding rvalues to ref [WAS: I close BIP27. I won't be pursuing BIPs anymore]

On Thursday, October 20, 2016 23:18:14 Nicholas Wilson via Digitalmars-d wrote: > On Thursday, 20 October 2016 at 01:04:35 UTC, Jonathan M Davis > > wrote: > > The transitivity of const shoot stuff in the foot pretty > > thoroughly in a number of cases. A prime example would be > > ranges,

Re: Binding rvalues to ref [WAS: I close BIP27. I won't be pursuing BIPs anymore]

On 10/21/2016 01:18 AM, Nicholas Wilson wrote: Is it legal to `.save` a const range, and then use it (provided it does not mutate any object reachable from bar)? Sure, if it doesn't involve a cast, i.e. if save is const.

Re: Binding rvalues to ref [WAS: I close BIP27. I won't be pursuing BIPs anymore]

On Thursday, 20 October 2016 at 01:04:35 UTC, Jonathan M Davis wrote: The transitivity of const shoot stuff in the foot pretty thoroughly in a number of cases. A prime example would be ranges, because they have to be mutated to be iterated over. If the function actually took a range directly,

Re: Binding rvalues to ref [WAS: I close BIP27. I won't be pursuing BIPs anymore]

On 10/19/16 9:04 PM, Walter Bright wrote: The only way to move this forward is to write a DIP. I'd be willing to shepherd a DIP if a couple of people want to get serious about it. -- Andrei

Re: Binding rvalues to ref [WAS: I close BIP27. I won't be pursuing BIPs anymore]

On 20 October 2016 at 11:04, Walter Bright via Digitalmars-d < digitalmars-d@puremagic.com> wrote: > On 10/19/2016 5:26 PM, Manu via Digitalmars-d wrote: > >> Right, I was arguing this for years. Using 'scope' to make the concept >> @safe. >> It seemed that it in the past the key reason for

Re: Binding rvalues to ref [WAS: I close BIP27. I won't be pursuing BIPs anymore]

On Thursday, October 20, 2016 10:23:35 Manu via Digitalmars-d wrote: > On 20 October 2016 at 01:38, Jonathan M Davis via Digitalmars-d < > > digitalmars-d@puremagic.com> wrote: > > On Wednesday, October 19, 2016 07:55:19 Andrei Alexandrescu via > > Digitalmars-d > > > > wrote: > > > This was C++'s

Re: Binding rvalues to ref [WAS: I close BIP27. I won't be pursuing BIPs anymore]

On 10/19/2016 5:26 PM, Manu via Digitalmars-d wrote: Right, I was arguing this for years. Using 'scope' to make the concept @safe. It seemed that it in the past the key reason for rejecting it was because it was unsafe to pass an rvalue-temp to a function where it's unknown if the function can

Re: Binding rvalues to ref [WAS: I close BIP27. I won't be pursuing BIPs anymore]

On 20 October 2016 at 04:18, Namespace via Digitalmars-d < digitalmars-d@puremagic.com> wrote: > On Wednesday, 19 October 2016 at 18:15:25 UTC, Jonathan M Davis wrote: > >> Which then causes the problem that it becomes much less clear whether ref >> is supposed to be modifying its argument or is

Re: Binding rvalues to ref [WAS: I close BIP27. I won't be pursuing BIPs anymore]

On 20 October 2016 at 01:38, Jonathan M Davis via Digitalmars-d < digitalmars-d@puremagic.com> wrote: > On Wednesday, October 19, 2016 07:55:19 Andrei Alexandrescu via > Digitalmars-d > wrote: > > This was C++'s big un' that led to many complications. If the overload > > weren't ambiguous, a

Re: Binding rvalues to ref [WAS: I close BIP27. I won't be pursuing BIPs anymore]

On Wednesday, 19 October 2016 at 19:19:35 UTC, Jonathan M Davis wrote: That's an orthogonal issue. My point is that normally, a parameter is a ref parameter, because the function is going to use that value and potentially mutate it in the process, and you want the original variable that was

Re: Binding rvalues to ref [WAS: I close BIP27. I won't be pursuing BIPs anymore]

On Wednesday, October 19, 2016 18:18:43 Namespace via Digitalmars-d wrote: > On Wednesday, 19 October 2016 at 18:15:25 UTC, Jonathan M Davis > > wrote: > > Which then causes the problem that it becomes much less clear > > whether ref is supposed to be modifying its argument or is just > > trying

Re: Binding rvalues to ref [WAS: I close BIP27. I won't be pursuing BIPs anymore]

On Wednesday, 19 October 2016 at 18:15:25 UTC, Jonathan M Davis wrote: Which then causes the problem that it becomes much less clear whether ref is supposed to be modifying its argument or is just trying to avoid copying it - though good documentation can mitigate that problem. - Jonathan M

Re: Binding rvalues to ref [WAS: I close BIP27. I won't be pursuing BIPs anymore]

On Wednesday, October 19, 2016 12:48:54 Andrei Alexandrescu via Digitalmars-d wrote: > On 10/19/2016 11:38 AM, Jonathan M Davis via Digitalmars-d wrote: > > On Wednesday, October 19, 2016 07:55:19 Andrei Alexandrescu via > > Digitalmars-d> > > wrote: > >> This was C++'s big un' that led to many

Re: Binding rvalues to ref [WAS: I close BIP27. I won't be pursuing BIPs anymore]

On 10/19/2016 11:38 AM, Jonathan M Davis via Digitalmars-d wrote: On Wednesday, October 19, 2016 07:55:19 Andrei Alexandrescu via Digitalmars-d wrote: This was C++'s big un' that led to many complications. If the overload weren't ambiguous, a large part of rvalue references would have been

Re: Binding rvalues to ref [WAS: I close BIP27. I won't be pursuing BIPs anymore]

On Wednesday, October 19, 2016 07:55:19 Andrei Alexandrescu via Digitalmars-d wrote: > This was C++'s big un' that led to many complications. If the overload > weren't ambiguous, a large part of rvalue references would have been > unneeded. (Universal references would still have been necessary

Binding rvalues to ref [WAS: I close BIP27. I won't be pursuing BIPs anymore]

On 10/19/16 1:47 AM, Manu via Digitalmars-d wrote: On 19 October 2016 at 06:22, Andrei Alexandrescu via Digitalmars-d > wrote: On 10/18/2016 04:15 PM, Atila Neves wrote: I think I get it; I'm just not sure given the