Immutable fields

[Jonathan M Davis]

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