rvalue references

[Manu]

On 27 April 2013 21:11, Andrei Alexandrescu
<SeeWebsiteForEmail at erdani.org>wrote:

> On 4/27/13 2:37 AM, Manu wrote:
>
>> scope ref T func(scope ref T t) { return t; }
>>
>> I think this solves the problem.
>>
>
> Consider:
>
> scope ref T func(scope ref T t) { return t; }
> scope ref T func2() { T t; return func(t); }
>

How does auto-ref address this problem?

I think the solution (and I think you proposed this yourself), is that it
must assume the lifetime of the returned ref to be the same as the argument
with the shortest life, since it can't know which argument was returned,
and it would need to be conservative.
In this case, it knows the lifetime of the argument 't', and that it's a
local. Since it is the shortest life argument, it can't return it from
func2(), because it knows the returned ref could be(/is, in this case) the
local supplied.

In the event the function was inlined, maybe there is opportunity to lift
this restriction, since it can know which argument was returned.

Would be great if you went through all of the existing work on this. Well
> after you're done preparing your DConf talks :o).


I've read the bug where you made your proposals and associated threads. I
think you actually proposed this same solution iirc?
I'm only adding to it that it makes sense for 'scope' to be present,
otherwise you eliminate other useful cases where you may want to return an
arbitrary ref that's not an argument at all.
The rule detailed above should only apply to scope-ref, since it's the only
case that could possibly deal with short-lived temporaries anyway.
If scope ref were implemented in this way, it could receive temp's of
r-values, and safely receive locals. I would then disallow passing local
variables to non-scope-ref args, as this remains fundamentally unsafe, as
it is now.
vanilla 'ref' becomes useful for receiving and returning unrestricted
references, but we gain the confidence that it can't deal with short-lived
stack variables, which solves the problem we have now.

The only issue I've seen raised that I'm not sure of a good solution for is
the one walter raised of conditionally executed statements. But I don't
think that's addressed by any of the designs discussed.
I haven't thought about that yet, but I'm sure a solution exists. I suspect
it will have something to do with splitting the statement containing
conditions into non-conditional sub-statements, and treating lifetimes
normally within the sub-statements...

On a side note, my second talk is almost done. Huzzah! I have slides...
it's a bit rough, but it's good enough for jazz. And it's a long flight...
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puremagic.com/pipermail/digitalmars-d/attachments/20130428/6f9dfa79/attachment.html>