auto ref is on the docket

[Jonathan M Davis via Digitalmars-d]

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.

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)" - and that the only place that scope does 
anything at all is with delegates, 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.

- Jonathan M Davis