• Michel Fortin (14/14) Mar 09 2010 This compiles, but should it?
• bearophile (6/7) Mar 10 2010 I think the @safe attribute is not significant here, because that code i...
• Norbert Nemec (5/11) Mar 10 2010 I would say the possibility of a bug makes this code unsafe by
• Michel Fortin (12/27) Mar 10 2010 Exactly. This means that half of std.range will have to be @trusted for
• Walter Bright (2/14) Mar 12 2010 No.

Michel Fortin <michel.fortin michelf.com> writes:

This compiles, but should it?

 safe
ref int foo(ref int a) {
	return a;
}

 safe
ref int bar() {
	int a;
	return foo(a); // leaking reference to a beyond bar's scope
}

-- 
Michel Fortin
michel.fortin michelf.com
http://michelf.com/

bearophile <bearophileHUGS lycos.com> writes:

Michel Fortin:
 This compiles, but should it?

I think the  safe attribute is not significant here, because that code is
wrong, in unsafe code too.
I think DMD lets it pass because it's not able to spot the bug. I don't know if
and when it will be able to trace such situations, but in the meantime:
http://d.puremagic.com/issues/show_bug.cgi?id=3925

Bye,
bearophile

Norbert Nemec <Norbert Nemec-online.de> writes:

bearophile wrote:
 Michel Fortin:
 This compiles, but should it?

 
 I think the  safe attribute is not significant here, because that code is
wrong, in unsafe code too.
 I think DMD lets it pass because it's not able to spot the bug. I don't know
if and when it will be able to trace such situations, but in the meantime:
 http://d.puremagic.com/issues/show_bug.cgi?id=3925

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.

Michel Fortin <michel.fortin michelf.com> writes:

On 2010-03-10 12:33:22 -0500, Norbert Nemec <Norbert Nemec-online.de> said:

 bearophile wrote:
 Michel Fortin:
 This compiles, but should it?

 
 I think the  safe attribute is not significant here, because that code 
 is wrong, in unsafe code too.
 I think DMD lets it pass because it's not able to spot the bug. I don't 
 know if and when it will be able to trace such situations, but in the 
 meantime:
 http://d.puremagic.com/issues/show_bug.cgi?id=3925

 
 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.

Exactly. This means that half of std.range will have to be  trusted for 
wrapper ranges like retro.

It also breaks what I think Andrei said once: that 'ref' as implemented 
in D is guarantied not to hold dangling references. (But perhaps that's 
not what he said, I can't remember exactly.) I hope this is not written 
in TDPL.

And thanks for filling the bug report bearophile.

-- 
Michel Fortin
michel.fortin michelf.com
http://michelf.com/

Walter Bright <newshound1 digitalmars.com> writes:

Michel Fortin wrote:
 This compiles, but should it?
 
  safe
 ref int foo(ref int a) {
     return a;
 }
 
  safe
 ref int bar() {
     int a;
     return foo(a); // leaking reference to a beyond bar's scope
 }

No.