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

On Tuesday, 19 January 2016 at 17:48:24 UTC, tsbockman wrote:
> 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 confused. You don't seem to be able to distinguish between indifference and lack of knowledge. I'm not here to analyze the finer points of you wrapper thingy that no one will ever use.

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

We need a consensus, not one person to convince Walter or Andrei. The more people that get on board with this, the more likely it is to actually get fixed. You don't have ZERO control over it, you have one vote.

The more that people try and hack their way around this problem, instead of speaking up about it, the less likely it is to get fixed.

    Bit

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

As a simple example, consider the following:

void main() {
    func(5);

    int n = 6;
    func(n);
}

Defining `func` by directly using `auto ref`, this:

void func()(auto ref int x)
{
    enum set_at_compile_time = __traits(isRef, x);
    writeln(set_at_compile_time);
}

Will be compiled into two separate functions:

void func1(int x) // pass by value
{
    writeln(false);
}

void func2(ref int x) // pass by ref
{
    writeln(true);
}

void main() {
    func1(5); // prints false

    int n = 6;
    func2(n); // prints true
}

(Try it here: http://dpaste.dzfl.pl/dc9af2059641)

Whereas using my PR:

void funcImpl(ref int x) {
    writeln(__traits(isRef, x));
}
mixin acceptRVals!("func", funcImpl);

It's effectively just one function:

void funcImpl(ref int x) {
    writeln(true);
}

void main() {
    int x = 5;
    funcImpl(x); // prints true

    int n = 6;
    funcImpl(n); // prints true
}

Note that the output IS NOT THE SAME.
(Try it yourself: http://dpaste.dzfl.pl/9ae30506b4a3)

If you don't understand why, then you have no business trying to dictate how the language should handle rvalues. You also don't fully understand why Manu's not satisfied with just using `auto ref` directly.

On Tuesday, 19 January 2016 at 18:03:05 UTC, bitwise wrote:
> I'm not here to analyze the finer points of you wrapper thingy
> that no one will ever use.

It's not a "finer point". This isn't really even about my wrapper at this point.

Why should anyone listen to your demands for changes to the language, when you don't even understand how the relevant features work now?

On Tuesday, 19 January 2016 at 18:18:30 UTC, tsbockman wrote:
> On Tuesday, 19 January 2016 at 18:03:05 UTC, bitwise wrote:
>> I'm not here to analyze the finer points of you wrapper thingy
>> that no one will ever use.
>
> It's not a "finer point". This isn't really even about my wrapper at this point.
>
> Why should anyone listen to your demands for changes to the language, when you don't even understand how the relevant features work now?

It's not that I don't understand, I just don't care to convince YOU that I do.

    Bit

On 01/19/2016 06:43 AM, bitwise wrote:
>
> 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.

It actually isn't.

On Tuesday, 19 January 2016 at 18:28:28 UTC, bitwise wrote:
> It's not that I don't understand, I just don't care to convince YOU that I do.
>
>     Bit

So because you "don't care" -> you argue with me about what my own code does.
Because you DO "understand" -> you give a point-by-point criticism that's completely wrong.

On Tuesday, 19 January 2016 at 18:30:26 UTC, Timon Gehr wrote:
> On 01/19/2016 06:43 AM, bitwise wrote:
>>
>> 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.
>
> It actually isn't.

Clearly, it is =)

   Bit

On 01/19/2016 07:43 PM, bitwise wrote:
> On Tuesday, 19 January 2016 at 18:30:26 UTC, Timon Gehr wrote:
>> On 01/19/2016 06:43 AM, bitwise wrote:
>>>
>>> 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.
>>
>> It actually isn't.
>
> Clearly, it is =)
>
>     Bit
>

The point isn't particularly original. It's come up in most sufficiently long threads about the issue.

Also, you seem to think that you don't miss the point and you are part of the community. It isn't a useful quote.

On Monday, 18 January 2016 at 17:48:39 UTC, Namespace wrote:
> You don't give up, huh? ;)

I'm glad he doesn't. I couldn't agree more with Manu. It's the one thing I really, I mean *really* detest about D.
To me, this rvalue-to-ref bindability is 100x more important than the GC. Yet it keeps on being neglected and worked around with `auto ref` hacks.

PS: I also hate the Roboto font (at least here on Windows w/ Firefox). :P