auto ref is on the docket

[Jonathan M Davis via Digitalmars-d]

On Saturday, 27 June 2015 at 11:10:49 UTC, Marc Schütz wrote:
> On Saturday, 27 June 2015 at 01:18:19 UTC, Jonathan M Davis 
> wrote:

> No, not with scope. It seems you're using the status quo to 
> argue against what could be. But that's not valid, because the 
> problems you mention will no longer exist with scope.

If we want to define what scope does and implement it, that's a 
separate issue from having a function accept both rvalues and 
lvalues with the same parameter. It would be trivial to have a 
function where you want to guarantee that no pointer to a ref 
parameter escapes but you still don't want to accept rvalues, 
because the whole point is to mutate the argument. Wanting to 
have a function accept lvalues and rvalues is thus fundamentally 
different from caring about issues with escaping. Yes, there is 
some overlap in terms of safety issues when it comes to returning 
by ref, but that's it, and the return attribute solves that 
problem, but whether you escape pointers to a parameter is 
fundamentally separate from whether a function should accept 
rvalues, because escaping is not the only issue, and ref itself 
has all of the same issues with escaping whether it accepts 
rvalues or not.

So, it really doesn't matter what scope might protect against in 
terms of escaping and what it might not if we were to fully 
define it (e.g. maybe it would protect against taking the address 
of a variable, and maybe not; that could be simply considered 
@system, or it could be protected against). We have to actually 
define it to know what it would or wouldn't do. All we have is 
the basic idea of what it's supposed to have been for. The _only_ 
thing that it applies to at this point is delegates. There's 
little point in arguing about what it could do until we're 
talking about actually defining it. But regardless, the issue of 
accepting rvalues by ref is orthogonal, because that is not 
solely an issue of escaping. It's also an issue of _why_ the 
argument is passed by ref in the first place.

>> We introduced the return attribute (currently only with 
>> -dip25) to fix this problem. So, with that, we eliminate the 
>> safety problem with ref itself, and we can safely have auto 
>> ref accept rvalues by having it assign them to a temporary 
>> variable first.
>
> Yes this is now possible, but why in all world do you want the 
> keyword that enables it to be `auto ref`?

That's what auto ref was originally introduced to do. The reason 
that it works only with templates is because Walter misunderstood 
what Andrei was proposing. So, it makes sense to use it for what 
it was originally intended for and implement it as proposed with 
non-templated functions. Now, that has the downside that we can't 
use it with templated functions in a fashion that avoids template 
bloat, in which case, using a new attribute would make sense, but 
this _is_ what auto ref was originally for. And if we're going to 
use a new attribute, scope ref makes no sense precisely because 
the escaping issue is only part of the problem with accepting 
lvalues and rvalues with the same parameter, since you could 
easily have a function which is not supposed to escape the 
argument in any way, and yet it needs to be mutating the argument 
via ref for the caller, and it should not be accepting rvalues. 
So, in that case, if scope were fully ironed out, it might make 
sense to use scope ref when the intention was that the argument 
be mutated and not accept rvalues and that in not escape the 
function. It could also be that scope ref prevents returning by 
ref, since that's escaping the function, whereas when you pass an 
rvalue to the non-templated auto ref, you may very well want to 
return it by ref. So, if we were to use scope ref for this, we'd 
be mixing two largely orthogonal issues - escaping arguments and 
having a function accept both lvalues and rvalues - and it would 
cause us problems if and when we actually, fully defined scope.

We need to either use auto ref for this as originally intended or 
use a new attribute which does so so that we can use it with both 
templated and non-templated functions. I think that it's quite 
clear that scope ref does _not_ make sense in this case, and it's 
already been rejected by Walter and Andrei anyway.

- Jonathan M Davis