On 06/03/2012 06:18 PM, Artur Skawina wrote:
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.
I see. The intended behaviour seems to be that immutable implies static
on fields with initializers.
Thanks!
Filed: http://d.puremagic.com/issues/show_bug.cgi?id=8192
