thoughts on immutability in D

Jonathan M Davis jmdavisProg at gmx.com
Sat Sep 24 00:07:35 PDT 2011


On Saturday, September 24, 2011 08:12:17 Rainer Schuetze wrote:
> On 9/22/2011 4:10 PM, Andrei Alexandrescu wrote:
> > On 9/22/11 3:02 AM, Peter Alexander wrote:
> >> On 22/09/11 7:04 AM, Andrei Alexandrescu wrote:
> >>> The initial submission got junked so I resubmitted:
> >>> 
> >>> http://www.reddit.com/r/programming/comments/knn5p/thoughts_on_immut
> >>> ability_in_d/
> >>> 
> >>> 
> >>> 
> >>> Andrei
> >> 
> >> Thanks for the reddit'ing. I launched up google analytics this morning
> >> and noticed a sudden spike. That could only mean one thing :-)
> >> 
> >> Out of interest, does anyone have any criticism of my post, esp. if
> >> there's any technical inaccuracies (or just disagreement?)
> > 
> > You could have specified that e.g. mutable state can be implemented
> > safely with the help of a global hash table.
> > 
> > Andrei
> 
> If this is allowed by the compiler, doesn't that break all the
> guarantees transitive immutability tries to make? Aren't we back to
> "faith based programming" this way?

In a way, yes. No, the object itself isn't altered, but by using such a hash 
table, you're effectively moving some of the state out of the class or struct. 
That state is then not regulated by const. If you did that with all of a 
type's member variables, then const would mean nothing. In order to truly 
guarantee that this isn't an issue, you have to combine const with pure.

However, it _is_ a way to have an object primarily const and still have some 
sort of logical const. Still, it strikes me as a bad idea unless you really 
need it for some reason, and the fact that it makes it so that you can't use 
pure is definitely not desirable.

- Jonathan M Davis


More information about the Digitalmars-d mailing list