On Thursday, 25 June 2015 at 08:04:09 UTC, kink wrote:
On Wednesday, 24 June 2015 at 23:30:53 UTC, Jonathan M Davis
wrote:
But this has _nothing_ to do with scope, and scope ref was
already rejected. The whole point of this is support having a
function accept both rvalues and lvalues, not to do anything
with scope.
And given that what scope does has never even been properly
defined - all that the spec says about scope parameters is
"references in the parameter cannot be escaped (e.g. assigned
to a global variable)".
Yeah right. And all we need to safely pass in rvalue references
is exactly the constraint that they won't escape. And scope
alone doesn't imply pass-by-ref (`in` params aren't currently
passed by ref).
Whether a reference escapes is an orthogonal issue. The return
attribute is for dealing with that. The function should be able
to return by ref or not and still accept both rvalues and lvalues
for its parameters. As long as the temporary variable created for
holding an rvalue exists for the duration of the statement that
the function call is in, it doesn't matter. It should be
perfectly fine to have the function return one of its ref
arguments by ref (and thus avoid a copy), even if it was
originally an rvalue, because it have been assigned to an lvalue
that would be around long enough. The only issue arises when the
caller then returns the return value by ref, in which case that's
going to be illegal without the return attribute. But in general,
the fact that a ref to an argument could be returned by ref is
orthogonal to being able to pass in both lvalues and rvalues,
because the rvalues all have to become lvalues to be passed in
anyway, in which case, you're in exactly the same place with
regards to safety that you are with normal ref.
[...] Before we can even consider what something like scope
ref might mean, we'd have to properly define what scope means.
And all we have for it is the basic idea of what it's supposed
to do - none of the details - and trying to define scope ref
before defining what scope means in general could totally
hamstring us when properly defining scope later.
Is there a roadmap for "later"? It seems like these things
always just get postponed, further postponed and never really
done.
Perhaps so, but just because scope hasn't properly defined yet
isn't a reason to use it for something else entirely right now -
especially when whether the lvalue that gets passed into the
function is returned by ref is an orthogonal issue to having a
type of ref which accepts an rvalue and silently converts it to
an lvalue so that it can be passed by ref.
- Jonathan M Davis
