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.
