rvalue references

[via Digitalmars-d]

On Tuesday, 2 June 2015 at 17:31:56 UTC, Jonathan M Davis 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`)?
>
> Because scope isn't even properly defined. Certainly, if we 
> were to go that route, we'd have to finish working out what the 
> heck scope is really supposed to do and mean. And we haven't 
> done that yet. As it stands, everyone has their own ideas about 
> what it means and/or should mean, but all the spec says for 
> scope parameters is that "references in the parameter cannot be 
> escaped (e.g. assigned to a global variable)", and right now, 
> the only thing that scope affects is delegate parameters, and 
> I'm not sure that even that works correctly yet or is properly 
> ironed out.
>
> So, while maybe using scope ref for this would make sense, we 
> have a _lot_ to figure out before we can really consider that.
>

That's what makes it an ideal choice in my opinion :-) Whatever 
semantics we give it is by definition not a breaking change...

Besides, I do have a pretty good idea what `scope` should mean, 
including most of the finer details. I summarized it here:
http://wiki.dlang.org/User:Schuetzm/scope3

The lack of progress on this topic is not because no solution is 
known.

>>> 4. What's with this constellation:
>>>
>>> struct S { }
>>>
>>> void ene(S) { }
>>> void mene(ref S) { }
>>> void muh(auto ref S) { }
>>>
>>> should 'mene' (ref) interfere with 'muh' (auto ref)?
>>
>> If overloading on `scope` is allowed, then yes, else no.
>
> It's not currently allowed. But regardless, if the whole point 
> of saying scope ref (or whatever attribute we picked) was to 
> indicate that we wanted the parameter to accept both lvalues 
> and rvalues, then it makes no sense whatsoever to overload the 
> parameter on ref, and it would be ref underneath the hood 
> anyway, because that's how it would have to be implemented.

There are use-cases for overloading on scope with value types, 
but there are other ways to achieve the same goals (see here: 
http://wiki.dlang.org/User:Schuetzm/scope3#scope_for_value_types_.26_overloading).