rval->ref const(T), implicit conversions

[tsbockman via Digitalmars-d]

On Tuesday, 19 January 2016 at 05:43:57 UTC, bitwise wrote:
> Sorry if that seemed mean, but it wasn't meant to be insulting. 
> But while your solution is clever, I find it totally 
> unrealistic.
>
> Why would anyone use it when they can just templatize their 
> function and get exactly the same thing?
>
> struct S{}
>
> void foo(ref const(S) s) {}
> becomes
> void foo()(auto ref const(S) s) {}

That has fundamentally different semantics from my PR, and does 
not solve Manu's problem at all. For example, this:

int foo()(auto ref int x) {
     return x + 1;
}

Is actually a template with two possible instantiations (that's 
why `auto ref` is disallowed on non-template functions):

// lvalues are passed by reference:
int foo(ref int x) {
    return x + 1;
}

// rvalues are passed by value:
int foo(int x) {
     return x + 1;
}

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.

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

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

By marking the wrapper `pragma(inline, true)` and forwarding 
everything to the all `ref` version of the function, my PR mostly 
solves (1), and entirely solves (2) and (3).

> Not to mention the fact that people's first reaction to D's ref 
> params not taking rvalues isn't going to be to look in the 
> standard library.
>
> Finally, this situation simply should not be this complicated. 
> A ref param should accept an rvalue. @safety is a specific 
> concern, and unless I'm annotating my code with @safe, I should 
> be able to write it however I want(within reason).
>
> To quote a famous author: "Sometimes, an entire community can 
> miss a point".
>
> This is one of those points.
>
> Most of my reaction is to the fact that this is actually a 
> problem. Sorry I offended you.
>
>     Bit

I understand, but please don't take it out on me. I have no more 
control over what gets into the compiler than you do.