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.).
