rvalue references

[Jonathan M Davis via Digitalmars-d]

On Wednesday, 3 June 2015 at 01:57:21 UTC, bitwise wrote:
> On Tue, 02 Jun 2015 14:06:31 -0400, Namespace 
> <rswhite4 at gmail.com> wrote:
>
>> On Tuesday, 2 June 2015 at 17:22:07 UTC, Marc Schütz wrote:
>>> On Tuesday, 2 June 2015 at 16:02:56 UTC, Namespace wrote:
>>>> Thanks to DIP 25 I think it's time to review this again. I 
>>>> would implement it (if no one else wants to do it), but 
>>>> there are still some unanswered questions:
>>>>
>>>> 1. Is 'auto ref' still the chosen syntax (I guess so)?
>>>
>>> Why not `scope ref` (or `in ref` == `const scope ref`)?
>>
>> See DIP 36
>>
>
> I'm feeling like a bit of a troll here, but I can't help myself.
>
> 'in' is currently useless because scope is not defined 
> properly, and const is too restrictive. Also, because of DIP25, 
> it's now even more useless. It seems a pretty sure bet that it 
> will either continue to be completely useless or be changed at 
> some point anyways, so why not now? If it's only been around 
> since 2.060, how bad could the code breakage really be? Replace 
> All a few times and you're done. A compiler warning could be 
> issued for the next few versions to notify users that the 
> meaning of 'in' has changed, if needed.
>
> So why not re-brand this awesomely concise and convenient 
> keyword to be the "non-template auto ref"?

Where on earth did you get the idea that in was introduced in 
2.060? in existed in D1. Its meaning was slightly different then, 
but it was kept in D2 and its meaning changed in a manner that 
was intended to be reasonably compatible with D1 code. And folks 
_love_ using in, because they view it as the opposite of out. 
Almost always, it's really just const, since scope really only 
applies to delegates at this point, but in is used _heavily_ by 
many folks in the D community.

I keep telling folks not to use in, because scope isn't 
well-defined yet, so who knows what's going to happen when we 
_do_ try and define it properly, but folks keep using it anyway. 
We can't just change the meaning and expect it not to break code. 
That's part of what's going to be so ugly about finishing scope. 
And there are folks who use in fully understanding the risks 
under the assumption that scope will be defined in a way that 
does what they want. So, many folks are relying on in being 
equivalent to const scope, and changing it to mean something else 
is just plain a bad idea.

- Jonathan M Davis