On 22 Jun 2015 08:40, "Andrei Alexandrescu via Digitalmars-d" < digitalmars-d@puremagic.com> wrote:
>
> On 6/21/15 11:31 PM, Andrei Alexandrescu wrote:
>>
>> On 6/21/15 10:25 PM, Walter Bright wrote:
>>>
>>> The idea is that fun(5) would be lowered to:
>>>
>>>     auto tmp = 5;
>>>     fun(tmp);
>>
>>
>> I don't think that lowering is recommended - it prolongs the lifetime of the temporary through the end of the caller. But that may be actually a good thing.
>
>
> On second thought - Walter's lowering, which makes the rvalue last more
than strictly necessary, may be the most flexible of all at the cost of more resource consumption (for types that define destructors). -- Andrei
>

I think keeping the lifetime of objects strictly in the call expression is the behaviour that will give least surprise.

int i = 42;
struct S { ~this() { i++; } }

// auto __autoreftmp = S();
foo(S());  // __autoreftmp
// __dtor(__autoreftmp);
assert(i == 43);

As for optimisations, I think it should be possible to assert that the reference never escapes, and use more aggressive optimisations based on that, something that is still not possible with 'scope ref' or 'in ref' parameters ...

Iain.

On Wednesday, 24 June 2015 at 00:23:42 UTC, Timon Gehr wrote:
> On 06/23/2015 03:01 AM, Andrei Alexandrescu wrote:
>> the perfect solution.
>
> We might as well do it right. Why promote unnecessary template bloat?

I'm fine with it either way, but given all of the template bloat that auto ref creates and how common templates are in D (and will only become more so as more stuff is range-based and uses design by introspection), the cost of auto ref generating extra template instantiations will only increase. So, I think that we'd be better off simply adding a new attribute like @anyref or whatever we want to call it. But I don't know how much it will ultimately matter.

- Jonathan M Davis

Simply give a possibility to "ref in" allowing use rvalues.
Don't add any new strange attributes.

On Wednesday, 24 June 2015 at 09:26:49 UTC, Temtaime wrote:
> Simply give a possibility to "ref in" allowing use rvalues.

That has already been rejected.

- Jonathan M Davis

On Wednesday, 24 June 2015 at 09:54:01 UTC, Jonathan M Davis wrote:
> On Wednesday, 24 June 2015 at 09:26:49 UTC, Temtaime wrote:
>> Simply give a possibility to "ref in" allowing use rvalues.
>
> That has already been rejected.
>
> - Jonathan M Davis

How many times did I say that already? :)

On Wednesday, 24 June 2015 at 10:02:12 UTC, Namespace wrote:
> On Wednesday, 24 June 2015 at 09:54:01 UTC, Jonathan M Davis wrote:
>> On Wednesday, 24 June 2015 at 09:26:49 UTC, Temtaime wrote:
>>> Simply give a possibility to "ref in" allowing use rvalues.
>>
>> That has already been rejected.
>>
>> - Jonathan M Davis
>
> How many times did I say that already? :)

Indeed.

- Jonathan M Davis

On Tuesday, 23 June 2015 at 19:13:28 UTC, bitwise wrote:
> And I still think Timon's statement is untrue. There is a reason, which is that the new auto ref syntax forces reference parameters for all types(even primitives), where the old template approach does not.

The "old template approach" isn't going anywhere. When used with templated functions, auto ref will continue to function the same way, and if you want that behavior, you templatize your function. AFAIK, there are really only two ways to tackle having a function accept both lvalues and rvalues for the same parameter:

1. Duplicate the entire function and have one overload take an lvalue and the other take an rvalue. This is what the the templated auto ref does (though which overloads get generated depends on what arguments are passed to the function).

2. Assign rvalues to an lvalue and pass that in to the function by ref. This is what's going to happen with non-templated functions. It's just a question of whether that's going to be done by introducing a temporary variable or by having the compiler add overloads which take rvalues and then call the primary function which takes its arguments by ref.

And at this point, I think that there are really only three options that we might take in making it so that we can have non-templated functions accept both lvalues and rvalues with the same function declaration:

1. Leave things as they are and not support it except with templated functions (not desirable, but that may be the result of all of this).

2. Implement auto ref for non-templated functions as currently proposed, leaving auto ref on templated functions exactly as it is and providing no way to use the non-templated behavior with templated functions (though _maybe_ we could add compiler optimizations later to use the non-templated version in cases where the compiler can detect that using the non-templated version with a templated function would have the same semantics as the templated version).

3. Add a new attribute which does what's being proposed for auto ref for non-templated functions, in which case, we can use the non-templated behavior with templates as well and thus avoid template bloat when all you want is for your templated function to accept both lvalues and rvalues. auto ref, of course, then stays exactly as it is now.

At the moment, it seems that #2 is the most likely, and that's probably fine, but I do wonder if we'd be better off with #3, especially when you consider how much D code tends to be templated and how much code bloat auto ref is likely to generate with templated functions.

- Jonathan M Davis

On Wednesday, 24 June 2015 at 11:19:04 UTC, Jonathan M Davis wrote:
> [...]
>
> 3. Add a new attribute which does what's being proposed for auto ref for non-templated functions, in which case, we can use the non-templated behavior with templates as well and thus avoid template bloat when all you want is for your templated function to accept both lvalues and rvalues. auto ref, of course, then stays exactly as it is now.
>
> At the moment, it seems that #2 is the most likely, and that's probably fine, but I do wonder if we'd be better off with #3, especially when you consider how much D code tends to be templated and how much code bloat auto ref is likely to generate with templated functions.
>
> - Jonathan M Davis

If that wasn't clear before, I'm all for #3 too. Just call it `scope ref` and simplify the PR a lil' bit as suggested by Marc in an earlier post [http://forum.dlang.org/post/ricvtchihgzyisbkzcgl@forum.dlang.org].

On Wednesday, 24 June 2015 at 09:54:01 UTC, Jonathan M Davis wrote:
> On Wednesday, 24 June 2015 at 09:26:49 UTC, Temtaime wrote:
>> Simply give a possibility to "ref in" allowing use rvalues.
>
> That has already been rejected.

Then we need to reconsider it. If that was several years ago, much has changed since then.

Can you point me to that decision? Who made it, and on what basis? I can't find anything in the threads linked in http://wiki.dlang.org/DIP36

On Wednesday, 24 June 2015 at 17:45:15 UTC, Marc Schütz wrote:
> On Wednesday, 24 June 2015 at 09:54:01 UTC, Jonathan M Davis wrote:
>> On Wednesday, 24 June 2015 at 09:26:49 UTC, Temtaime wrote:
>>> Simply give a possibility to "ref in" allowing use rvalues.
>>
>> That has already been rejected.
>
> Then we need to reconsider it. If that was several years ago, much has changed since then.
>
> Can you point me to that decision? Who made it, and on what basis? I can't find anything in the threads linked in http://wiki.dlang.org/DIP36

Read the thread: http://forum.dlang.org/thread/ylebrhjnrrcajnvtthtt@forum.dlang.org?page=1