www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Immutable fields

reply bearophile <bearophileHUGS lycos.com> writes:
Is it correct for immutable struct fields to act like enum or static const
fields? (I don't think so, but I am wrong often):

struct Foo {
    immutable int x = 1;
}
static assert(Foo.sizeof == 4);
void main() {}


More info in the D.learn thread:
http://www.digitalmars.com/webnews/newsgroups.php?art_group=digitalmars.D.learn&article_id=22540

Thank you,
bearophile
Nov 02 2010
next sibling parent reply "Daniel Murphy" <yebblies nospamgmail.com> writes:
"bearophile" <bearophileHUGS lycos.com> wrote in message 
news:iaqbsb$1d30$1 digitalmars.com...

 Is it correct for immutable struct fields to act like enum or static const 
 fields? (I don't think so, but I am wrong often):


immutable struct fields can be changed inside the constructor, so they must 
be non-static.

stuct S
{
    immutable int a;
    this(int b)
    {
        a = b;
    }
}
Nov 02 2010
next sibling parent reply bearophile <bearophileHUGS lycos.com> writes:
Daniel Murphy:


 immutable struct fields can be changed inside the constructor, so they must 
 be non-static.


So do you think my code shows a compiler bug?

Bye,
bearophile
Nov 02 2010
next sibling parent reply "Daniel Murphy" <yebblies nospamgmail.com> writes:
"bearophile" <bearophileHUGS lycos.com> wrote in message 
news:iaqgvl$1qbp$1 digitalmars.com...

 So do you think my code shows a compiler bug?


I'd like immutable to be implicitly static in some cases eg.

void foo()
{
    immutable int[20] table = [...];
}

If this is possible, it does reduce the storage required and repeated init 
times.  (Although it seems to be using enum, not static, which has its own 
set of problems)

Removing the storage inside structs completely scews up the memory layout 
(which is meant to be C compatible)

The fact that commenting out the constructor in struct C changes the size of 
the struct seems like a bug to me, or at least a horribly messy part of the 
spec.

struct A
{
    int x;
}
struct B
{
    immutable int x;
}
struct C
{
    immutable int x;
    this(int a) { x = a; }
}

Also, this seems to work for me.


enum E { A, B };

struct Foo {
    immutable E x;
 this(int dummy) { x = E.A; }
}

struct Bar {
    immutable E x;
 this(int dummy) { x = E.B; }
}

void main() {

 auto f = Foo(0);
 assert((cast(Bar*)&f).x == E.A);
}


Also, What the hell?
Nov 02 2010
parent Leandro Lucarella <luca llucax.com.ar> writes:
Daniel Murphy, el  3 de noviembre a las 13:52 me escribiste:

 "bearophile" <bearophileHUGS lycos.com> wrote in message 
 news:iaqgvl$1qbp$1 digitalmars.com...

 So do you think my code shows a compiler bug?


 
 I'd like immutable to be implicitly static in some cases eg.
 
 void foo()
 {
     immutable int[20] table = [...];
 }


I think immutable should NEVER, EVER be optimized-out from a struct, for
the reasons I gave in the other post.

I really hope this IS a bug, if D would like to stay being a system
programming language. Struct are extremely important to represent memory
layouts, and making that incompatible with immutable seems extremely
silly.

-- 
Leandro Lucarella (AKA luca)                     http://llucax.com.ar/
----------------------------------------------------------------------
GPG Key: 5F5A8D05 (F8CD F9A7 BF00 5431 4145  104C 949E BFB6 5F5A 8D05)
----------------------------------------------------------------------
El techo de mi cuarto lleno de galaxias
Nov 02 2010
prev sibling parent "Daniel Murphy" <yebblies nospamgmail.com> writes:
*What the hell?

struct Foo {
    immutable int x = 3;
 this(int dummy) { auto p = &x; }
}

void main() {

 auto f = Foo(0);

 auto p = &f.x; // Will compile with this commented out
}
Nov 02 2010
prev sibling parent reply Stewart Gordon <smjg_1998 yahoo.com> writes:
On 03/11/2010 03:06, Daniel Murphy wrote:

 "bearophile"<bearophileHUGS lycos.com>  wrote in message
 news:iaqbsb$1d30$1 digitalmars.com...

 Is it correct for immutable struct fields to act like enum or static const
 fields? (I don't think so, but I am wrong often):


 immutable struct fields can be changed inside the constructor, so they must
 be non-static.


<snip>

Const/immutable struct members are an ugly mess, and a big hole in the 
const system.

http://d.puremagic.com/issues/show_bug.cgi?id=2625

Stewart.
Nov 07 2010
parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 11/7/10 2:40 PM, Stewart Gordon wrote:

 On 03/11/2010 03:06, Daniel Murphy wrote:

 "bearophile"<bearophileHUGS lycos.com> wrote in message
 news:iaqbsb$1d30$1 digitalmars.com...

 Is it correct for immutable struct fields to act like enum or static
 const
 fields? (I don't think so, but I am wrong often):


 immutable struct fields can be changed inside the constructor, so they
 must
 be non-static.


 <snip>

 Const/immutable struct members are an ugly mess, and a big hole in the
 const system.

 http://d.puremagic.com/issues/show_bug.cgi?id=2625

 Stewart.


There are problems with the implementation, not the design. Fixing const 


Andrei
Nov 07 2010
next sibling parent Jonathan M Davis <jmdavisProg gmx.com> writes:
On Sunday 07 November 2010 17:13:51 Andrei Alexandrescu wrote:

 There are problems with the implementation, not the design. Fixing const



Now, _that_ is good news. The problems with const and immutable have long been 
some of the most annoying.

- Jonathan M Davis
Nov 07 2010
prev sibling parent Jacob Carlborg <doob me.com> writes:
On 2010-11-08 02:13, Andrei Alexandrescu wrote:

 On 11/7/10 2:40 PM, Stewart Gordon wrote:

 On 03/11/2010 03:06, Daniel Murphy wrote:

 "bearophile"<bearophileHUGS lycos.com> wrote in message
 news:iaqbsb$1d30$1 digitalmars.com...

 Is it correct for immutable struct fields to act like enum or static
 const
 fields? (I don't think so, but I am wrong often):


 immutable struct fields can be changed inside the constructor, so they
 must
 be non-static.


 <snip>

 Const/immutable struct members are an ugly mess, and a big hole in the
 const system.

 http://d.puremagic.com/issues/show_bug.cgi?id=2625

 Stewart.


 There are problems with the implementation, not the design. Fixing const


 Andrei


Why can't we get an official roadmap for this? I thought dynamic 
libraries was next after 64bit.

-- 
/Jacob Carlborg
Nov 08 2010
prev sibling next sibling parent reply Jonathan M Davis <jmdavisProg gmx.com> writes:
On Tuesday 02 November 2010 17:54:35 bearophile wrote:

 Is it correct for immutable struct fields to act like enum or static const
 fields? (I don't think so, but I am wrong often):
 
 struct Foo {
     immutable int x = 1;
 }
 static assert(Foo.sizeof == 4);
 void main() {}
 
 
 More info in the D.learn thread:
 http://www.digitalmars.com/webnews/newsgroups.php?art_group=digitalmars.D.l
 earn&article_id=22540
 
 Thank you,
 bearophile


Assuming that it's the constructor which initializes the variable, then it's 
going to have to have storage, immutable or not. However, if it's not set by
the 
constructor but directly initialized, then I don't see why the compiler can't 
treat it as not having storage. At that point, it's conceptually the same as 
using an enum. Why would it really matter though? If anything, I would have 
thought that the elimination of the storage would be a good thing, since it 
reduces the memory footprint of the object.

- Jonathan M Davis
Nov 02 2010
parent reply bearophile <bearophileHUGS lycos.com> writes:
Jonathan M Davis:


 Why would it really matter though?


I guess you have not followed my link with more explanations, right? :-)

Bye,
bearophile
Nov 02 2010
parent reply Jonathan M Davis <jmdavisProg gmx.com> writes:
On Tuesday 02 November 2010 19:24:29 bearophile wrote:

 Jonathan M Davis:

 Why would it really matter though?


 
 I guess you have not followed my link with more explanations, right? :-)
 
 Bye,
 bearophile


I don't really get what you're doing there or what the problem is. You cast one 
struct to another struct and it retained the same value for x. That seems 
logical enough. You're just viewing that chunk of memory as a new type. You 
didn't actually change what's there. My first reaction to seeing that sort of 
cast though is that it's a bad idea anyway, though I guess that whether an 
immutable variable has storage could affect the result in such a case.
Generally 
though, I would have argued that if you weren't going to set the variable with 
the constructor, it should probably be an enum anyway.

- Jonathan M Davis
Nov 02 2010
parent reply Leandro Lucarella <luca llucax.com.ar> writes:
Jonathan M Davis, el  2 de noviembre a las 20:02 me escribiste:

 On Tuesday 02 November 2010 19:24:29 bearophile wrote:

 Jonathan M Davis:

 Why would it really matter though?


 
 I guess you have not followed my link with more explanations, right? :-)
 
 Bye,
 bearophile


 
 I don't really get what you're doing there or what the problem is. You cast
one 
 struct to another struct and it retained the same value for x. That seems 
 logical enough. You're just viewing that chunk of memory as a new type. You 
 didn't actually change what's there. My first reaction to seeing that sort of 
 cast though is that it's a bad idea anyway, though I guess that whether an 
 immutable variable has storage could affect the result in such a case.
Generally 
 though, I would have argued that if you weren't going to set the variable with 
 the constructor, it should probably be an enum anyway.


I don't think it's a good idea to optimize out a struct member, as
structs are often used to represent memory layouts when interacting with
low level stuff (or not so low-level, like reading and writing a packet
from the network). It seems pretty silly to have to avoid using
immutable in those cases just to let the compiler "please, don't remove
store from this struct".

-- 
Leandro Lucarella (AKA luca)                     http://llucax.com.ar/
----------------------------------------------------------------------
GPG Key: 5F5A8D05 (F8CD F9A7 BF00 5431 4145  104C 949E BFB6 5F5A 8D05)
----------------------------------------------------------------------
Y2K
- what a disappointment... i had at least expected one nuclear plant to blow
Nov 02 2010
parent Jonathan M Davis <jmdavisProg gmx.com> writes:
On Tuesday 02 November 2010 21:00:00 Leandro Lucarella wrote:

 Jonathan M Davis, el  2 de noviembre a las 20:02 me escribiste:

 On Tuesday 02 November 2010 19:24:29 bearophile wrote:

 Jonathan M Davis:

 Why would it really matter though?


 
 I guess you have not followed my link with more explanations, right?
 :-)
 
 Bye,
 bearophile


 
 I don't really get what you're doing there or what the problem is. You
 cast one struct to another struct and it retained the same value for x.
 That seems logical enough. You're just viewing that chunk of memory as a
 new type. You didn't actually change what's there. My first reaction to
 seeing that sort of cast though is that it's a bad idea anyway, though I
 guess that whether an immutable variable has storage could affect the
 result in such a case. Generally though, I would have argued that if you
 weren't going to set the variable with the constructor, it should
 probably be an enum anyway.




Perhaps, but is it reasonable to be worrying about memory layouts like that
when 
you're dealing with immutable? I would have thought that in cases where memory 
layouts like that mattered, you wouldn't be using immutable, since you're 
probably interfacing with C code or somesuch.

It may be that we ultimately don't want to make immutable be optimized away 
(since you can just use an enum instead if you do want it to be optimized
away), 
but it doesn't surprise me at all if the decision was made to optimize 
immutables away, since at first glance, at least, it seems like a good 
optimization and that there's no real need to keep it around if you can
optimize 
it out.

- Jonathan M Davis
Nov 02 2010
prev sibling next sibling parent reply Gareth Charnock <gareth.charnock gmail.com> writes:
On 03/11/10 00:54, bearophile wrote:

 Is it correct for immutable struct fields to act like enum or static const
fields? (I don't think so, but I am wrong often):

 struct Foo {
      immutable int x = 1;
 }
 static assert(Foo.sizeof == 4);
 void main() {}


 More info in the D.learn thread:
 http://www.digitalmars.com/webnews/newsgroups.php?art_group=digitalmars.D.learn&article_id=22540

 Thank you,
 bearophile


If it helps, the analogy I always use when explaining immutable is the 
stone tablet. A running program can chip out a message on a stone tablet 
(write to immutable memory) but once it's written once it's never going 
to change again. When your done with a stone tablet all you can do is 
throw it in the garbage but you can go and chip a new message on a new 
stone tablet.

Don't worry, it took me a while before I realized that an immutable 
didn't have to be known at compile time as well.
Nov 02 2010
parent Gareth Charnock <gareth.charnock gmail.com> writes:
On 03/11/10 02:20, Gareth Charnock wrote:

 On 03/11/10 00:54, bearophile wrote:

 Is it correct for immutable struct fields to act like enum or static
 const fields? (I don't think so, but I am wrong often):

 struct Foo {
 immutable int x = 1;
 }
 static assert(Foo.sizeof == 4);
 void main() {}


 More info in the D.learn thread:
 http://www.digitalmars.com/webnews/newsgroups.php?art_group=digitalmars.D.learn&article_id=22540


 Thank you,
 bearophile


 If it helps, the analogy I always use when explaining immutable is the
 stone tablet. A running program can chip out a message on a stone tablet
 (write to immutable memory) but once it's written once it's never going
 to change again. When your done with a stone tablet all you can do is
 throw it in the garbage but you can go and chip a new message on a new
 stone tablet.

 Don't worry, it took me a while before I realized that an immutable
 didn't have to be known at compile time as well.


Ah, okay, I reread that. You meant is it correct for immutable to act 
like enum at any time, but I read all the time for some reason. Sorry.
Nov 02 2010
prev sibling parent reply "Lars T. Kyllingstad" <public kyllingen.NOSPAMnet> writes:
On Tue, 02 Nov 2010 20:54:35 -0400, bearophile wrote:


 Is it correct for immutable struct fields to act like enum or static
 const fields? (I don't think so, but I am wrong often):



This is bug 3449:

http://d.puremagic.com/issues/show_bug.cgi?id=3449

-Lars
Nov 03 2010
next sibling parent bearophile <bearophileHUGS lycos.com> writes:
Lars T. Kyllingstad:


 This is bug 3449:
 
 http://d.puremagic.com/issues/show_bug.cgi?id=3449


Thank you to you and the others that have answered in this thread. That's an
important bug, it changes how much I can use immutables.

Bye,
bearophile
Nov 03 2010
prev sibling parent Bruno Medeiros <brunodomedeiros+spam com.gmail> writes:
On 03/11/2010 10:42, Lars T. Kyllingstad wrote:

 On Tue, 02 Nov 2010 20:54:35 -0400, bearophile wrote:


 Is it correct for immutable struct fields to act like enum or static
 const fields? (I don't think so, but I am wrong often):



 This is bug 3449:

 http://d.puremagic.com/issues/show_bug.cgi?id=3449

 -Lars


Ouch, this is a very nasty bug indeed. :S

-- 
Bruno Medeiros - Software Engineer
Nov 25 2010