non-instance accessibility of immutable instance variables with initializers

[Artur Skawina]

On 06/03/12 17:31, Simen Kjaeraas wrote:
> On Sun, 03 Jun 2012 15:40:32 +0200, Timon Gehr <timon.gehr at gmx.ch> 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.