rvalue references

[Jonathan M Davis via Digitalmars-d]

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.

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

- Jonathan M Davis