The Status of Const

[Jonathan M Davis]

On Thursday, August 12, 2010 18:12:25 dsimcha wrote:
> == Quote from Brad Roberts (braddr at slice-2.puremagic.com)'s article
> 
> > For discussions like this, I think it's essential to distinguish between
> > the language vs the runtime + core libraries.  I recognize what matters
> > is the end result usability, but examining the layers independently is
> > really important.
> > So, which are you talking about (could well be both)?
> 
> I disagree.  A major reason why the libraries are broken is because the
> language is broken.  const/immutable is very hard to use with generic
> code, meaning that anything short of impeccable discipline and testing
> will lead to bugs galore. Fixing the language would make it a lot easier
> to fix the libraries.

I see three primary issues with const/immutable beyond whatever bugs we have, 
and while improvement to the libraries would help, I'm not sure that they can fix 
them.

1. The fact that const references make both the reference and the referent 
const.

Rebindable!() works to some extent, but it really feels like a hack and is 
nowhere near as smooth as some kind of tail const solution would be (though I do 
understand that having head const and tail const would complicate things 
considerably). I think that it would have been far better had const and 
immutable references just made the referent const/immutable. There just _has_ to 
be a better way to handle it. Maybe have rconst for references or something. It 
almost tempts me to see if I should just try and use pointers everywhere instead 
of references.

2. The shear difficulty in getting in getting immutable versions of stuff. There is 
no automated way to do it other than idup with arrays.

I really don't know the cleanest way to solve this. The nature of immutable 
makes casting to it not work, so you're going to have to make a copy, and if 
that needs a deep copy, you're going to need clone() for classes and a copy 
constructor or assignment operator for structs. It's not at all obvious how to 
make this cleaner. Maybe there could be a function in Phobos that abstracts it 
out; it would know the correct, standard way to get an immutable copy of 
classes, structs, arrays, etc. and return the appropriate type. Then generic 
code could just use that function. Still, getting immutable copies of stuff which 
isn't always immutable is not pretty.

3. The lack of a mutable modifier.

There are times when you need a mutable modifier to sanely use const (it 
obviously wouldn't work with immutable regardless). I don't know if there's any 
way to safely do this with a library or not. It just seems like a deficiency in 
the language itself. As I understand it, Walter thinks that there are serious 
issues with mutable in C++, and I don't know what those are, but I know that 
there are going to be cases where I'd like my code to be const-correct, and I 
won't be able to because there is no mutable in D.

I really don't know how many of these issues can be fixed at this stage in the 
game, and ultimately, the current bugs in dmd make them pretty much a moot issue 
because the bugs make using const and immutable near impossible in many cases. 
Still, it would be nice to resolve these issues in a better manner than what we 
currently have does.

- Jonathan M Davis