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).
[...] 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. What
about the original argument 2 years ago, when rejecting DIP36,
where Andrei explained that the idea was to make `ref` itself not
escapable and delegating escaping refs to pointers? I don't see
how that could be implemented without a breaking change, so I
guess that may be something for D3. But we have been needing a
solution for rvalue refs for years, and, as you know, are waiting
since then, as `auto ref` for templates alone is simply not
enough.
To quote Manu from the DIP36 thread:
It is, without doubt, the single biggest complaint I've heard
by virtually every programmer I've introduced D to.
+1 kazillion
