auto ref is on the docket

[Manu via Digitalmars-d]

On 22 June 2015 at 23:49, Jonathan M Davis via Digitalmars-d
<digitalmars-d at puremagic.com> wrote:
> On Monday, 22 June 2015 at 13:23:47 UTC, Marc Schütz wrote:
>>
>> On Monday, 22 June 2015 at 04:11:41 UTC, Andrei Alexandrescu wrote:
>>>
>>> Walter and I discussed what auto ref for templates should look like and
>>> reached the conclusion that an approach based on lowering would be best. I
>>> added a proposed lowering to
>>> https://github.com/D-Programming-Language/dmd/pull/4717.
>>
>>
>> I have to concur with Manu's statement in the PR. IMO `auto ref` (i.e. the
>> status quo) is a hack introduced because of the lack of usable `scope`. We
>> shouldn't spread it to other parts of the language, at least not for rvalue
>> references. `scope ref` is the perfect fit for those.
>>
>> (There may still be a use for `auto ref` with the meaning "pass this as
>> efficiently as possible, I don't care whether it's a reference or not", but
>> I'm not convinced of that either.)
>
>
> I'm afraid that I don't understand this. What on earth does scope have to do
> with this issue? We need a way to indicate that a parameter should accept
> both lvalues and rvalues.

This is what I don't understand; why does this have anything to do
with rvalues/lvalues specifically?
An rvalue is just a temporary. It can safely be passed to anything
that we can be sure won't keep a reference to it; that's why escape
analysis seems to be the best approach.
This problem extends beyond rvalues, there are other forms of
temporaries which exhibit the exact same problem, ie, an rvalue
written to the stack explicitly on the line prior to the function
call:

f(vec3(1,2,3)); // onoes, comple error!

vec3 v = vec3(1,2,3);
f(v); // no worries bro!

This is accepted today, but the safety of the operation is identical
to the rejected line above. This is the de facto means to 'work
around' the problem, and it's just a pointless nuisance.
Both problems should be dealt with in the same way.

> auto ref was supposed to do that originally, but
> Walter misunderstood what Andrei was proposing and implemented what we have
> now, which is great for forwarding, but it doesn't solve the general case,
> because it only works with templates. That means that if we want that
> functionality we then need to either implement auto ref for non-templated
> functions as originally intended, or we need to come up with a new attribute
> which does that and which could be used with both templated and
> non-templated functions (thus not requiring the extra template bloat of the
> current auto ref implementation with templates if all you want is to accept
> both lvalues and rvalues, not have the refness of the argument forwarded).

It's been proposed repeatedly for years. 'scope' as a means of
expressing borrowing or escape analysis would solve the problem
elegantly, in addition to other uses.

There was also an idea Walter had at dconf 13, where he could do
runtime checking similar to range checking for safety validation,
thereby allowing unqualified ref args to receive temporaries safely.

> What on earth does _any_ of that have to do with scope? Theoretically, scope
> indicates that a variable isn't supposed to escape the function - whatever
> that really means (it's never actually been defined outside of delegates,
> and even there, I'm not sure that it's defined all that well). What does
> that have to do with accepting lvalues or rvalues?

If a parameter was scope, it can safely receive an rvalue.