auto ref is on the docket

kink via Digitalmars-d digitalmars-d at puremagic.com
Tue Jun 30 03:12:25 PDT 2015


On Monday, 29 June 2015 at 19:10:07 UTC, Atila Neves wrote:
> It seems to me that there's a lot of confusion in this thread. 
> I think I understand what you're saying but I'm not sure 
> everyone else does. So correct me if I'm wrong: your stance 
> (which is how I understand how things should be done in D) is 
> that if a person wants to bind an rvalue to a ref parameter for 
> performance, they shouldn't; they should pass it by value since 
> it'll either get constructed in place or moved, not copied.
>
> Essentially, what this guy said about C++ (not the original I 
> read, that's now a 404):
>
> http://m.blog.csdn.net/blog/CPP_CHEN/17528669
>
> The reason rvalue references even exist in C++11/14 is because 
> rvalues can bind to const&. I remember hearing/reading Andrei 
> say that D doesn't need them precisely because in D, they 
> can't. Pass by value and you get the C++ behaviour when rvalue 
> references are used: a move.

In some cases even better, in-place construction. That's perfect 
- for rvalues, as you said. But for lvalues, a copy must be made 
- afaik, you don't have the option to explicitly move an lvalue 
into a byval-param in D as you can in C++. And even moving can be 
expensive if the type is big.
So for efficiency, template auto-ref is a nice option, but 
requires a template and leads to code-bloat if both lvalues and 
rvalues are used as arguments. For these reasons, we want to have 
the additional option to pass both lvalues and rvalues by ref.

Jonathan wants a non-templated function to specify explicitly 
whether it wants to accept an rvalue by ref, apparently to 
discriminate between 'output parameters' (mutable `ref`, lvalues 
only) and another category of `auto ref` parameters which also 
accept rvalues via lowering (I don't know how one would describe 
that category - to me it seems completely arbitrary and adds 
complexity, not to mention different interpretations by different 
developers).

I'm solely interested in the safety of binding rvalues to refs, 
meaning that the compiler should prevent these rvalue refs from 
being escaped (I'm not talking about returning the ref via 
`return ref`, which is safe anyway when propagating the 
rvalue/lvalue origin, but storing derived pointers in external 
state). That's where `scope ref` (unescapable reference) comes 
in. But I prefer the compiler to infer scope-ness automatically 
in the future and would thus like to allow binding rvalues to 
`ref` in general - for not-so-performance-critical functions 
taking a value type by reference (for some value types, copying 
just doesn't make sense - streams, loggers etc.).


More information about the Digitalmars-d mailing list