auto ref is on the docket

[via Digitalmars-d]

On Wednesday, 24 June 2015 at 23:30:53 UTC, Jonathan M Davis 
wrote:
> On Wednesday, 24 June 2015 at 16:39:22 UTC, kink wrote:
>> On Wednesday, 24 June 2015 at 11:19:04 UTC, Jonathan M Davis 
>> wrote:
>>> [...]
>>>
>>> 3. Add a new attribute which does what's being proposed for 
>>> auto ref for non-templated functions, in which case, we can 
>>> use the non-templated behavior with templates as well and 
>>> thus avoid template bloat when all you want is for your 
>>> templated function to accept both lvalues and rvalues. auto 
>>> ref, of course, then stays exactly as it is now.
>>>
>>> At the moment, it seems that #2 is the most likely, and 
>>> that's probably fine, but I do wonder if we'd be better off 
>>> with #3, especially when you consider how much D code tends 
>>> to be templated and how much code bloat auto ref is likely to 
>>> generate with templated functions.
>>>
>>> - Jonathan M Davis
>>
>> If that wasn't clear before, I'm all for #3 too. Just call it 
>> `scope ref` and simplify the PR a lil' bit as suggested by 
>> Marc in an earlier post 
>> [http://forum.dlang.org/post/ricvtchihgzyisbkzcgl@forum.dlang.org].
>
> But this has _nothing_ to do with scope, and scope ref was 
> already rejected. The whole point of this is support having a 
> function accept both rvalues and lvalues, not to do anything 
> with scope.

It everything to do with scope, and I already explained it 
several times. As for the rejection, see my answer to Namespace:
http://forum.dlang.org/post/yxruhtwjllozgvpbhgik@forum.dlang.org

>
> And given that what scope does has never even been properly 
> defined - all that the spec says about scope parameters is 
> "references in the parameter cannot be escaped (e.g. assigned 
> to a global variable)"

Even this current vague definition is already enough of a 
guarantee to allow rvalue references with it. Of course I'd be 
the last to object against a more detailed specification, 
obviously.

> - and that the only place that scope does anything at all is 
> with delegates,

That's simply the status quo of the implementation and therefore 
can't be used as an argument.

> 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.