rvalues -> ref (yup... again!)

John Colvin john.loughran.colvin at gmail.com
Sat Mar 24 11:57:25 UTC 2018


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


More information about the Digitalmars-d mailing list