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.