Rvalue references - The resolution

[Timothee Cour]

> In fact it's also possible to know that these don't return a reference to
their parameter.

Watch out for this:
Struct S {double x;}
ref double foo(ref S a){return a.x;}

This sounds hacky. I've proposed a general solution here:
http://wiki.dlang.org/DIP38
either with user annotations of ref-return functions (scheme A) (just
distinguishing ref vs scope ref), or with compiler taking care of
annotations (scheme B).

On Sun, May 26, 2013 at 1:21 PM, Martin Nowak <code at dawg.eu> wrote:

> On 05/05/2013 12:30 AM, Walter Bright wrote:
> > On 5/4/2013 3:03 PM, deadalnix wrote:
> >>> Where you miss the point, is that these annotations may be omitted
> >>> (and they
> >>> are most of the time). When nothing is specified, the lifetime of the
> >>> returned
> >>> reference is considered to be the union of the lifetime of parameters
> >>> lifetime, which is what you want in 99% of cases.
> >>
> >> Note : We may also choose the lack of explicit lifetime means runtime
> >> check as
> >> proposed, instead of being an error.
> >
> > D omits the check when it can prove that the returned ref is not a ref
> > to one of the parameters that is local.
>
> ref int foo(ref int a, ref int b);
>
> It's a very nice observation that calling foo with only non-local
> references means that the returned reference is non-local too.
> In a way this works like inout but with a safe default so
> that no annotation is needed.
>
> In fact it's also possible to know that these don't return a reference to
> their parameter.
>
> ref double foo(ref int a);
>
> Struct S {}
> ref double foo(ref S a);
>
> It can become somewhat complicated to check though.
>
> Anyhow I think using flow-analysis to omit runtime checks is a nice
> approach.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puremagic.com/pipermail/digitalmars-d/attachments/20130526/e167cd82/attachment.html>