rval->ref const(T), implicit conversions

[tsbockman via Digitalmars-d]

On Tuesday, 19 January 2016 at 17:23:33 UTC, bitwise wrote:
> 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.

You seem to have missed the significance of the "including the 
body!" part. Directly using `auto ref` results in all the code in 
THE BODY of the function being recompiled once *per 
instantiation*.

Mine just recompiles THE WRAPPER, which is tiny and force 
inlined, and therefore should not bloat the generated binary at 
all.

It will still slow down compilation a bit, but nowhere near as 
much as recompiling an arbitrarily large function body 2^N times.

>> 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.

Whether a name is attached to it or not, a temporary will be 
created on the stack in the calling function.

My wrapper passes a pointer to that stack location to the actual 
function implementation, rather than copying it into the stack 
frame of the function being called. This allows the same 
generated code to be used for the function, regardless of whether 
an rvalue or lvalue is passed.

>> 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 obviously confused about either about how template 
instantiation works in D, or about the mechanics of pass-by-ref 
versus pass-by-value. I'm not sure which.

> 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.

I have no idea why you keep trying to argue with me about the 
language design. I already agreed it would be better to just 
directly support passing rvalues to `ref` (or preferably, 
`scope`) parameters in the compiler.

But again, I have ZERO control over this. I am not the one you 
need to convince - Walter and Andrei are.

The fact that *I know* that I'm not in charge of the language 
design does not mean I am "missing the point".