http://d.puremagic.com/issues/show_bug.cgi?id=3925
Don <clugd...@yahoo.com.au> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |clugd...@yahoo.com.au
--- Comment #2 from Don <clugd...@yahoo.com.au> 2010-03-10 11:12:03 PST ---
(In reply to comment #1)
> This was the original code by Michel Fortin:
>
> @safe ref int foo(ref int a) {
> return a;
> }
> @safe ref int bar() {
> int a;
> return foo(a);
> }
>
>
> Norbert Nemec comments:
> >I would say the possibility of a bug makes this code unsafe by definition.
> >Ref returns must be considered unsafe by default, unless the compiler can
> >know for sure that the object will exist beyond the lifetime of the
> >function.<
>
>
> So I think Norbert Nemec idea is: while the normal compiler error messages
> assume correctness and need a demonstration of unsafety to be shown, @safe can
> do the opposite assuming unsafety and requiring a demonstration of safety.
I've just been dealing with ref returns in my recent CTFE patch. But I don't
think it's very complicated.
As far as I can tell, ref returns are only a problem if a local variable is
passed as a ref parameter, or if it is a member function of a local struct.
If either of those is true, it should be considered to potentially be a return
of a local variable.
I don't think there's any problem with foo, but bar should generate an error.
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
