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.
