On Monday, 29 June 2015 at 17:19:48 UTC, Jonathan M Davis wrote:
On Sunday, 28 June 2015 at 10:50:10 UTC, Marc Schütz wrote:
The main problems with this is that they aren't in fact
orthogonal: `auto ref` without `scope ref` almost only makes
sense if you want to deliberately break something.
Furthermore, `auto ref` is already taken for something else,
and I'm not sure Walter would be too happy if we wanted to
change its meaning for templates.
We definitely don't want to lose the current auto ref that we
have with templates. It's critical for forwarding refness, even
if we got that ability by accident.
- snip -
For the record, to avoid further misunderstandings: When I talked
about "auto ref" I meant the proposed rvalue refs, not the
existing syntax for templates. I don't have such a strong opinion
about the latter, except that it is - and should stay - distinct
from rvalue refs.
Regardless, all of that is orthogonal to the escaping issue,
because the escaping issue exists for all ref variables (not
just those which refer to temporary variables that rvalues were
assigned to). So, whether a ref parameter accepts both lvalues
and rvalues is separate from whether they escape. And if scope
really prevented the ref from escaping, then you couldn't even
return it, and we need to be able to return by ref, so scope
ref really doesn't make sense in the context of preventing ref
parameters from existing longer than their arguments. It's
related, but it would be too restrictive if it truly prevented
all escaping.
It's not as strict as that. Returning an rvalue ref is not per se
unsafe, because the temporary that it refers to lives until the
end of the current statement, which can be longer than the
current call. It can be safely passed to another function as an
rvalue ref, e.g. in a UFCS chain. This is what the `return`
attribute enables: it's a means of telling the callee to losen
the restrictions on a scoped reference a bit, because the caller
is aware of it and can handle it in a safe way.
And as far as escaping references to ref parameters by
returning them by ref goes, the recently added return attribute
already takes care of that. So, arguably, it overlaps with what
scope conceivably could or should do, but it does what's
required for solving the escape problem for ref, and a more
general scope solution is not required for that. It also allows
us to distinguish between ensuring that a ref parameter does
not exist longer than is safe (i.e. that it's only returned by
ref if it's safe to do so) and preventing a ref parameter from
escaping the function at all. So, if we were to ever add scope
ref, then presumably that would have to do with other types of
escaping than simply returning by ref. And whether you wanted
to prevent a ref parameter from escaping - either by being
returned by ref or by other means - isn't necessarily related
to whether it refers to a temporary variable that was an
rvalue, much as it's clearly more dangerous to escape anything
which refers to a ref parameters if it refers to a temporary
variable that won't last beyond the statement that the function
was called in.
I already addressed this point in the last section of
http://forum.dlang.org/post/[email protected]
