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
