www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - non-instance accessibility of immutable instance variables with initializers

reply Timon Gehr <timon.gehr gmx.ch> writes:
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?
Jun 03 2012
parent reply "Simen Kjaeraas" <simen.kjaras gmail.com> writes:
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.
Jun 03 2012
parent reply Artur Skawina <art.08.09 gmail.com> writes:
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.
Jun 03 2012
parent Timon Gehr <timon.gehr gmx.ch> writes:
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
Jun 03 2012