On Friday, 23 March 2018 at 22:01:44 UTC, Manu wrote:
Forked from the x^^y thread...
On 23 March 2018 at 12:16, Walter Bright via Digitalmars-d
<digitalmars-d@puremagic.com> wrote:
On 3/23/2018 11:09 AM, Manu wrote:
[...]
Rvalue references are not trivial and can have major
unintended consequences. They're a rather ugly feature in C++,
with weirdities. I doubt D will ever have them.
Can you please explain these 'weirdities'?
What are said "major unintended consequences"?
Explain how the situation if implemented would be any different
than
the workaround?
This seems even simpler than the pow thing to me.
Rewrite:
func(f());
as:
{ auto __t0 = f(); func(__t0); }
I understand what you want, but I'm struggling to understand why
it's such a huge deal.
The reason you want to pass by reference is for performance, to
avoid copying the data at the call boundary.
So there are 2 cases: an lvalue needs to be passed, or an rvalue
needs to be passed.
1. The address of the lvalue is passed.
2. The rvalue is copied to a local, then the address of that
local is passed.
So in the rvalue case, you're not getting the performance benefit
of passing by reference, because you have to copy to a local
anyway.
What I would do in D currently to get the same performance and
API:
void foo(float[32] v) { foo(v); }
void foo(ref float[32] v) { ... }
or
void foo()(auto ref float[32] v) { ... }
What is so totally unacceptable about those solutions? I
personally like the second because it scales better to multiple
parameters. I know you have said it's not relevant and annoying
that people bring up auto ref, but I dont' get how or why. It's
exactly D's solution to the problem.
There's a little more work to be done when thinking about
extern(C++) and/or virtual functions, but most code for most
people isn't made of virtual extern(C++) functions that take
large value types can't accept the cost of copying a few lvalues.
