non-instance accessibility of immutable instance variables with initializers

Timon Gehr timon.gehr at gmx.ch
Sun Jun 3 10:22:39 PDT 2012


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<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.

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






More information about the Digitalmars-d mailing list