auto ref is on the docket

[Jonathan M Davis via Digitalmars-d]

On Thursday, 25 June 2015 at 08:04:09 UTC, kink wrote:
> On Wednesday, 24 June 2015 at 23:30:53 UTC, Jonathan M Davis 
> wrote:
>> 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)".
>
> Yeah right. And all we need to safely pass in rvalue references 
> is exactly the constraint that they won't escape. And scope 
> alone doesn't imply pass-by-ref (`in` params aren't currently 
> passed by ref).

Whether a reference escapes is an orthogonal issue. The return 
attribute is for dealing with that. The function should be able 
to return by ref or not and still accept both rvalues and lvalues 
for its parameters. As long as the temporary variable created for 
holding an rvalue exists for the duration of the statement that 
the function call is in, it doesn't matter. It should be 
perfectly fine to have the function return one of its ref 
arguments by ref (and thus avoid a copy), even if it was 
originally an rvalue, because it have been assigned to an lvalue 
that would be around long enough. The only issue arises when the 
caller then returns the return value by ref, in which case that's 
going to be illegal without the return attribute. But in general, 
the fact that a ref to an argument could be returned by ref is 
orthogonal to being able to pass in both lvalues and rvalues, 
because the rvalues all have to become lvalues to be passed in 
anyway, in which case, you're in exactly the same place with 
regards to safety that you are with normal ref.

>> [...] 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.
>
> Is there a roadmap for "later"? It seems like these things 
> always just get postponed, further postponed and never really 
> done.

Perhaps so, but just because scope hasn't properly defined yet 
isn't a reason to use it for something else entirely right now - 
especially when whether the lvalue that gets passed into the 
function is returned by ref is an orthogonal issue to having a 
type of ref which accepts an rvalue and silently converts it to 
an lvalue so that it can be passed by ref.

- Jonathan M Davis