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