auto ref is on the docket

[via Digitalmars-d]

On Monday, 29 June 2015 at 17:19:48 UTC, Jonathan M Davis wrote:
> On Sunday, 28 June 2015 at 10:50:10 UTC, Marc Schütz wrote:
>> The main problems with this is that they aren't in fact 
>> orthogonal: `auto ref` without `scope ref` almost only makes 
>> sense if you want to deliberately break something. 
>> Furthermore, `auto ref` is already taken for something else, 
>> and I'm not sure Walter would be too happy if we wanted to 
>> change its meaning for templates.
>
> We definitely don't want to lose the current auto ref that we 
> have with templates. It's critical for forwarding refness, even 
> if we got that ability by accident.
> - snip -

For the record, to avoid further misunderstandings: When I talked 
about "auto ref" I meant the proposed rvalue refs, not the 
existing syntax for templates. I don't have such a strong opinion 
about the latter, except that it is - and should stay - distinct 
from rvalue refs.

> Regardless, all of that is orthogonal to the escaping issue, 
> because the escaping issue exists for all ref variables (not 
> just those which refer to temporary variables that rvalues were 
> assigned to). So, whether a ref parameter accepts both lvalues 
> and rvalues is separate from whether they escape. And if scope 
> really prevented the ref from escaping, then you couldn't even 
> return it, and we need to be able to return by ref, so scope 
> ref really doesn't make sense in the context of preventing ref 
> parameters from existing longer than their arguments. It's 
> related, but it would be too restrictive if it truly prevented 
> all escaping.

It's not as strict as that. Returning an rvalue ref is not per se 
unsafe, because the temporary that it refers to lives until the 
end of the current statement, which can be longer than the 
current call. It can be safely passed to another function as an 
rvalue ref, e.g. in a UFCS chain. This is what the `return` 
attribute enables: it's a means of telling the callee to losen 
the restrictions on a scoped reference a bit, because the caller 
is aware of it and can handle it in a safe way.

> And as far as escaping references to ref parameters by 
> returning them by ref goes, the recently added return attribute 
> already takes care of that. So, arguably, it overlaps with what 
> scope conceivably could or should do, but it does what's 
> required for solving the escape problem for ref, and a more 
> general scope solution is not required for that. It also allows 
> us to distinguish between ensuring that a ref parameter does 
> not exist longer than is safe (i.e. that it's only returned by 
> ref if it's safe to do so) and preventing a ref parameter from 
> escaping the function at all. So, if we were to ever add scope 
> ref, then presumably that would have to do with other types of 
> escaping than simply returning by ref. And whether you wanted 
> to prevent a ref parameter from escaping - either by being 
> returned by ref or by other means - isn't necessarily related 
> to whether it refers to a temporary variable that was an 
> rvalue, much as it's clearly more dangerous to escape anything 
> which refers to a ref parameters if it refers to a temporary 
> variable that won't last beyond the statement that the function 
> was called in.

I already addressed this point in the last section of 
http://forum.dlang.org/post/udnrkqmfqeunsfgwscnk@forum.dlang.org