About ref used for performance reasons with struct

[kinke]

On Tuesday, 12 February 2013 at 13:59:45 UTC, Namespace wrote:
> Read my approach. I suggest something like A& a. It's short and 
> known from C++.

... where A& stands for a reference to an A instance. But in your 
approach it denotes either a plain A instance OR a reference to 
it, so I don't like your suggestion at all, I'm afraid. 
Additionally, afaik D/DMD (?) already implements move semantics 
for rvalues, so 1) the goal of your approach is already 
implemented and 2) the existing optimization doesn't require any 
special parameter denotation (plain A is fine).

> Only in my approach, I suggest a link between the proposal of 
> deadalnix (compiler optimizations) and generally rvalue 
> references.

Yes, and I'd extend it for the illustrated lvalue cases as well.

> 'const ref' will never work the way as we know it from C++. 
> Walter and Andrei and many others are totally against it.

And there are many others totally in favour of it. ;) I'm still 
waiting for a plausible argument as to why the callee needs to 
know whether a passed const reference actually references an 
lvalue or an rvalue. I'm tired of this const ref discussion, and 
probably many others are too.

> However, 'auto ref' is also not a real solution, because 'auto 
> ref' generates 2^(n - 1) permuationen of the same function - 
> code bloat.

That's what I said basically regarding the current 'auto ref' 
implementation.

> 'auto ref' accept of course lvalues and rvalues but you gain no 
> performance.

Of course you'd gain performance because lvalues would not be 
copied (just like 'ref' only). But in contrast to 'ref', you'd 
also be able to pass rvalues directly (byref), without having to 
overload the function or turn the rvalue manually to an lvalue 
right before the call.

The thing is that with 'auto ref', you have to determine if the 
struct is suited for copy-elision and then decorate the params 
manually with 'auto ref'/'const auto ref'/'const ref' ;). 
deadalnix listed some good reasons why the compiler should do 
that for us. But I think I also mentioned good reasons as to why 
the compiler most likely can't due to the huge complexity 
involved to make sure code doesn't break. Although it is unlikely 
to break in most cases, an optimization feature such as this 
needs to work for ALL cases.

This is why I suggested applying deadalnix' intended implicit 
move semantics only for rvalues and the mentioned, safe lvalue 
cases. Afaik D already implements move semantics for rvalues, but 
I guess it doesn't optimize the lvalue cases. For all other 
cases, I think we sadly need to resort to a revisited 'auto ref' 
approach.