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.

Reply via email to