auto ref is on the docket
kink via Digitalmars-d
digitalmars-d at puremagic.com
Thu Jun 25 01:04:08 PDT 2015
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
More information about the Digitalmars-d
mailing list