On 15 December 2012 19:45, H. S. Teoh <hst...@quickfur.ath.cx> wrote:
> On Sat, Dec 15, 2012 at 11:31:22AM -0800, Jonathan M Davis wrote: > > On Saturday, December 15, 2012 19:50:34 Iain Buclaw wrote: > > > On Saturday, 15 December 2012 at 18:38:29 UTC, H. S. Teoh wrote: > > > > With latest git dmd: > > > > auto makeVoldemort(int x) { > > > > > > > > struct Voldemort { > > > > > > > > @property int value() { return x; } > > > > > > > > } > > > > return Voldemort(); > > > > > > > > } > > > > void main() { > > > > > > > > auto v = makeVoldemort(); > > > > writeln(v.value); > > > > > > > > } > > > > > > > > Compile error: > > > > test.d(3): Error: function test.makeVoldemort.Voldemort.value > > > > > > > > cannot access frame of function test.makeVoldemort > > > > > > > > Changing 'struct' to 'class' works. Is this deliberate, or is it a > > > > bug? It is certainly inconsistent with Walter's article on > > > > Voldemort types, which uses structs as examples. > [...] > > > Pretty certain it's deliberate. No closure is created for nested > > > structs to access it's parent, complying with it's POD behaviour. > > > > static nested structs don't have access to their outer scopes. > > Non-static structs do. This reeks of a bug. > [...] > > Found the reference in TDPL, ยง7.1.9 (p.263): > > Nested structs embed the magic "frame pointer" that allows them > to access outer values such as a and b in the example above. > [...] If you want to define a nested struct without that > baggage, just prefix struct with static in the definition of > Local, which makes Local a regular struct and consequently > prevents it from accessing a and b. > > Ironically enough, Andrei in the subsequent paragraph discourages the > use of such nested structs, whereas Walter's article promotes the use of > such Voldemort types as a "happy discovery". :) > > Anyway, filed a bug: > > http://d.puremagic.com/issues/show_bug.cgi?id=9162 > > If it is one, it's a bug in FuncDeclaration::getLevel. -- Iain Buclaw *(p < e ? p++ : p) = (c & 0x0f) + '0';