auto ref is on the docket

[Timon Gehr via Digitalmars-d]

On 06/25/2015 10:28 AM, "Marc =?UTF-8?B?U2Now7x0eiI=?= 
<schuetzm at gmx.net>" wrote:
>
>
>> trying to expand it with "scope ref" as if that were simply an
>> extension of scope makes no sense. Before we can even consider what
>> something like scope ref might mean, we'd have to properly define what
>> scope means. And all we have for it is the basic idea of what it's
>> supposed to do - none of the details - and trying to define scope ref
>> before defining what scope means in general could totally hamstring us
>> when properly defining scope later.
>
> I can assure you that it will not limit us. The very concept of
> borrowing/scope already requires some very specific restrictions with
> regards to what a function is allowed to do with a scope parameter.
> These same restrictions guarantee that it's allowed to pass an rvalue to
> it. Every working scope proposal will always guarantee that, or it
> wouldn't be usable.
>
> If you still fear that it will impede us later, then at least this
> current proposal needs to be deferred until we have a scope proposal and
> have decided on it.

I think the arguments against allowing rvalues with scope ref are the 
same as those against allowing rvalues with ref, modulo accidental 
escaping. (It has been argued that 'ref' signifies an intent to modify, 
which I wouldn't necessarily agree with.)