On 06/03/12 17:31, Simen Kjaeraas wrote: > On Sun, 03 Jun 2012 15:40:32 +0200, Timon Gehr <[email protected]> wrote: > >> DMD 2.059: >> >> struct S{ >> immutable x = [1]; >> immutable y = 1; >> } >> >> void main(){ >> writeln(S.x); // ok >> writeln(&S.x); // ok >> writeln(S.y); // ok >> // writeln(&S.y); // error >> with(S) writeln(&y); // ok (but resulting pointer is wrong) >> } >> >> This behaviour is obviously buggy, but I am not sure to what extent. >> >> What is the intended behaviour? Should initialised immutable instance >> variables be accessible without an instance at all? > > > It gets worse: > > writeln(S.sizeof); // 1, which is the same as an empty struct > S s; > writeln(&s); // Gives a good pointer > writeln(&s.x); // Gives a completely different pointer > // (the same as for &S.x) > > This should show clearly that the compiler treats these as enum instead of > immutable, and thus do not leave them in the struct. >
It's completely broken - the struct layout depends on whether the field has an initializer - something that may be legal for classes [1], but isn't for structs. Requiring 'static' is fine, there's no need for that kind of compiler magic. The attempts to access TYPE.field using my old GDC result in ICE, BTW. artur [1] and i'm not saying it's good idea, just the way it currently is.
