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

[Manu]

On 26 March 2018 at 15:48, Walter Bright via Digitalmars-d
<digitalmars-d at puremagic.com> wrote:
> On 3/26/2018 12:24 PM, Manu wrote:
>>
>> On 26 March 2018 at 07:40, Atila Neves via Digitalmars-d
>>>
>>> C++ const T& -> D T
>>
>>
>> Yeah, no... T may be big. Copying a large thing sucks. Memory copying
>> is the slowest thing computers can do.
>> As an API author, exactly as in C++, you will make a judgement on a
>> case-by-case basis on this matter. It may be by-value, it may be by
>> const-ref. It depends on a bunch of things, and they are points for
>> consideration by the API author, not the user.
>
>
> Copying does suck, I agree. Consider the following:
>
>     void foo(T t) { foo(t); } <= add this overload
>     void foo(ref T t) { ... }
>     T aaa();
>
>     foo(aaa());
>
> With inlining, I suspect we can get the compiler to not make any extra
> copies. It's not that different from NRVO. And as a marvy bonus, no weird
> semantic problems (as Atila mentioned).

It's a terrible experience to add 2^n overloads, just to abuse the
parameter list (as in your example) to create the temporary in an
implicit manner. The compiler can easily create the exact same
temporary without requiring a bunch of overloads to be declared.
What's the advantage of requiring that effort from the user, rather
than just doing it at the call site?
There's side effects to that hack too. Now there are overloads; so
taking function pointers becomes awkward (might be important in some
cases). If the interface has a binary boundary (static lib/dll) then
what does that look like with respect to inlining? Where do the
overloads go if the function is virtual?
I already know the answers to these questions, but the point is,
there's a whole lot more baggage introduced into the scene that just
doesn't need to be there.

So, while I agree that's an existing workaround, it kinda misses the
point. This thread isn't about inlining, it's about NOT inlining. You
don't use ref args unless you have a reason to, and that reason is
likely to have friction with that particular work-around.