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.