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

[Rubn]

On Sunday, 25 March 2018 at 01:43:43 UTC, Jonathan M Davis wrote:
> On Sunday, March 25, 2018 00:34:38 Rubn via Digitalmars-d wrote:
>> On Saturday, 24 March 2018 at 23:03:36 UTC, John Colvin wrote:
>> > Auto ref allows the unnecessary copy to be avoided for 
>> > lvalues and creates a temporary (as part of passing the 
>> > value) for rvalues. It has downsides (virtual functions and 
>> > extern(C++), but it does directly address the problem you're 
>> > talking about, unless I have totally misunderstood you.
>>
>> You are trading syntax bloat for binary bloat. Having 4 
>> parameters with auto ref can generate 16 different variants 
>> for the exact same function. If you are doing any sort of 
>> mathematical calculations you could cause a potential cache 
>> miss for calling the same exact function because one of your 
>> parameters didn't end up being the same type of value. You are 
>> causing all this bloat and potential slowdowns all to avoid 
>> having to do this:
>>
>> float value0 = a + b;
>> float value1 = c + d;
>> float value2 = e + f;
>> someFunc(value0, value1, value2);
>>
>> That's an inherent flaw in design. You obviously agree that 
>> there is a problem, but how can you justify "auto ref" being a 
>> "good" solution to the problem? It's a horrible one, it causes 
>> excessive bloat and potential slowdowns just to get a cleaner 
>> readable syntax. That shouldn't be a solution that is deemed 
>> acceptable.
>
> How good or bad it is depends on what you're doing and how many 
> auto ref parameters there are in your code. If you're using it 
> occasionally, it's not a problem at all, whereas if you're 
> using it all over the place, you do get a lot of template bloat.
>
> Regardless, John's point was that auto ref solves the problem 
> of being able to call a function with both lvalues and rvalues 
> without copying lvalues, and he didn't understand why anyone 
> was trying to argue that it doesn't do that. And I agree with 
> him on that point. It does not help with virtual functions or 
> extern(C++), and it creates a lot of template bloat if it's 
> used heavily, so there are downsides to it, but it _does_ solve 
> the basic problem of being able to call a function with both 
> lvalues and rvalues without copying the lvalues. It just 
> doesn't solve it in a way that everyone considers acceptable.

That's a horrible way to look at it. You can still technically 
drive a car with square wheels, it may not be a very comfortable 
or efficient ride, but it still __does__ solve the basic problem 
of moving the car. Because it works we shouldn't look at any 
other solution.

> auto ref also helps with forwarding refness, so it's useful for 
> more than just avoiding copying lvalues, but the entire reason 
> that auto ref was originally added to the language was to solve 
> this exact problem. And maybe we need a different solution for 
> some use cases (like virtual functions or cases where the 
> template bloat is deemed unacceptable), but auto ref is in the 
> language to solve this problem. So, much as at may make sense 
> to argue that it's not a good solution to this problem, it 
> really doesn't make sense to argue that it has nothing to do 
> with it.

I never said it has nothing to do with it. It's just a really 
horrible solution.

If you are going to add an exception just for two minor cases, at 
that point you might as well start looking at adding rvalue 
references, cause that's what it is going to lead to. It'd 
provided better integration with C++ and provide an 
__acceptable__ solution to the problem (not one that solves the 
problem in a roundabout square-wheel-like way) that doesn't 
create runtime bloat and slowdown just to have clean readable 
syntax.