rval->ref const(T), implicit conversions

[bitwise via Digitalmars-d]

On Tuesday, 19 January 2016 at 06:17:17 UTC, tsbockman wrote:
> On Tuesday, 19 January 2016 at 05:43:57 UTC, bitwise wrote:
>> [..]
>
> There are several problems with this:
>
> 1) It introduces substantial template bloat, as the number of 
> instantiations of the entire function - including the body! - 
> scales as the square of the number of `auto ref` parameters.

Your solution suffers from exactly the same problem. It still 
uses auto ref.

> 2) rvalues will be passed by value, which could be slow if the 
> type is bulkier than `int`.

No, they won't. Temporaries will be created for rvalues, and 
lvalues will be passed by ref.

> 3) `auto ref` CANNOT be used on an extern(C++) function, 
> because the rvalue calls won't link!

This is the _one_ advantage that your solution actually has over 
simply templatizing the function.

You are still missing the point though. This shouldn't even be a 
problem in the first place. It's faulty language design. This 
limitation makes no sense, and should be removed. There is no 
argument anyone can make that isn't totally broken.

Having ref params not take rvalues doesn't make the language any 
safer or more intuitive at all.

If rvalues were allowed to be passed to ref params, the 
temporaries would be constructed on the stack right before the 
function call. It's already possible to have variables on the 
stack and pass them to ref params. There is no difference.

In terms of conveying intention to the caller, just make the 
param const and you're done.

Finally, for a language that is nearly 1:1 compatible with C++ in 
many areas, people will expect familiar semantics. There is no 
real reason to deviate here. At the very least, extern(C++) 
functions with ref params could take rvalues.

    Bit