auto ref is on the docket

Iain Buclaw via Digitalmars-d digitalmars-d at puremagic.com
Wed Jun 24 11:26:57 PDT 2015


On 24 June 2015 at 19:48, via Digitalmars-d <digitalmars-d at puremagic.com> wrote:
> On Wednesday, 24 June 2015 at 07:12:53 UTC, Iain Buclaw wrote:
>>
>> On 22 Jun 2015 08:40, "Andrei Alexandrescu via Digitalmars-d" <
>> digitalmars-d at 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.
>
>
> Call expression, or statement containing the call expression? For normal
> temporaries, it's the latter AFAIK.
>

I suppose DMD doesn't have an equivalent, but they are called
BIND_EXPR in GCC, where you have a new local block with assigned
temporaries that expire outside of the given bind.

>>
>> int i = 42;
>> struct S { ~this() { i++; } }
>>
>> // auto __autoreftmp = S();
>> foo(S());  // __autoreftmp
>> // __dtor(__autoreftmp);
>> assert(i == 43);
>
>
> It would make a difference for:
>
>     auto x = foo(S()) + foo(S());
>

It works like this, the last result is binded back to the lvalue.

auto x =  {
    tmpA = S();
    tmpB = S();

    foo(tmpA) + foo(tmpB);
}

>>
>> 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 ...
>
>
> Not possible because it's not implemented, or are there fundamental reasons
> against it?

Ignoring the 'ref' part of my comment, so as we are not confusing
DIP36 (which I've only just learned about). The last time I checked,
the use of 'scope' and 'in' on parameters are ignored by escape
analysis, so you can quite happily escape a reference as you see fit
and the language will allow you to do that.

So, I cannot optimised if the language allows you to break that
optimisation without warning or erroring the user.  If I did, then
ultimately you'll end up seeing your programs becoming silently
corrupted.


More information about the Digitalmars-d mailing list