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?

On Sun, 03 Jun 2012 15:40:32 +0200, Timon Gehr <timon.gehr@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.

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

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