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: -------