auto ref is on the docket

[via Digitalmars-d]

On Saturday, 27 June 2015 at 01:18:19 UTC, Jonathan M Davis wrote:
> On Saturday, 27 June 2015 at 00:13:08 UTC, kinke wrote:
>> When I was talking about escaping references, I didn't mean 
>> returned references; I meant storing a pointer to a ref 
>> parameter somewhere outside (global/instance variable).
>
> That's a completely orthogonal issue to ref or auto ref. That's 
> an @system operation (since taking the address of a local 
> variable is @system), and it's up to you to not screw it up. 
> scope might cover that if it were fully ironed out, since that 
> does involve escaping, but it also might not, since it's an 
> @system operation and thus up to you not to screw it up.

The point is that with scope, it _doesn't_ need to be @system 
anymore. As an example where this can be useful, see:
https://github.com/D-Programming-Language/phobos/blob/41d2027c22d6f8d22edd2df688c3cfd08fb20228/std/digest/hmac.d#L252
We currently can't make this function @safe, although it is in 
fact memory safe.

> Regardless, it has nothing to do with whether the function 
> accepts lvalues and rvalues with the same parameter. You have a 
> safety issue regardless if you're talking about taking a 
> pointer to an argument (or to some portion of the argument), 
> since there's no guarantee that the lifetime of the pointer is 
> shorter than that of the argument.

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.

> 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`?

> The rules with returning by ref would then be the same with 
> auto ref as ref and require the return attribute to return a 
> parameter. And all of this is within @safe code.
>
> Any issues with taking pointers to arguments is firmly in 
> @system territory and is thus completely orthogonal. Even if 
> scope were to be implemented in a way that prevented it, it 
> would still have nothing to do with whether the function 
> accepted both rvalues and lvalues with the same parameter.
>
>> In the meantime, what about making all `ref` params accept 
>> rvalues
>
> Please, please, no. ref indicates that your intention is to 
> mutate the argument. Having it accept rvalues completely 
> destroys that and makes it that much harder to understand what 
> a function is supposed to do.

I can accept that argument, although I see cases where it's still 
justified. For example, if the author of the function decided it 
wants to mutate the argument, but you (the caller) are not 
interested in the new value. But still, explicitly using a 
temporary named `dummy` is preferable because it even documents 
that you're going to ignore it.

> By having a separate attribute such as auto ref which also 
> accepts rvalues, we cleanly separate out the code which just 
> wants to accept both rvalues and lvalues for efficiency 
> purposes and the code that actually wants to take its argument 
> by ref so that it can mutate it.

Okay, then you mainly want to use special syntax to opt-in to 
rvalue references. I simply think that `auto ref` is completely 
inadequate for this purpose, because its existing meaning with 
templates doesn't have anything to do with rvalue refs.

`scope ref` on the other hand is more fitting IMO. It's not that 
`scope` necessarily implies rvalue refs, but rvalue refs _do_ 
imply scope! If we go with DIP25 where `ref` by itself already 
implies that, `scope ref` would then be redundant, and therefore 
the syntax would be available for the special purpose of 
accepting rvalue refs. This has multiple advantages:

- No new keywords or @attributes.
- Rvalue refs are still opt-in, you don't get them accidentally 
just by writing `ref`.
- It reinforces the guarantee that the argument will not escape.
- It's usable in templates, too, with the same meaning as in 
normal functions.