D const design rationale

[Robert Fraser]

 >  * constant don't mean read only, so even though const can be considered to
> mean constrained, it don't, and should thus not be used to mean read only.
> Oskar's suggestion readonly is the best yet. Add to the damage of the new
> const that it in 1.0 always mean immutable. Looking to C++/listening to C++
> users in this respect may be the worst mistake in D's history yet.
>  * invariant as the keyword for immutable/constant would have been ok, if it
> hadn't been for the fact that it is used in another context, where empty ()
> had to be added to separate from the immutable meaning. The easy fix is of
> course to use const to mean immutable/constant, since readonly should be
> used to mean read only.
>  * const-by-default has been completely ignored/put down, even if _everyone_
> giving their opinion in the newsgroup said "give it a try"
> 

Up to here, I totally agree with you.

> Then there are some things that at least appears to be inconsistent:
> 
>  * why are D string literals invariant(char)[] whereas C string literals are
> invariant(char*) ? This probably ties in with why invariant(char*) and
> invariant(char[]) behaves differently in the first place.
> 

Not sure about the C string thing, but now that I understand the difference, I think it's important that invariant(char[]) and invariant(char)[], and specifying it like that seems a hell of a lot easier than some C++ism along the lines of "invariant char invariant[]".

> I'm sure there are other questions to ask, or that have already been asked.
> 
> Walter, I think it's time to pick up your promise again, to have D go
> wherever the community wants it to go. This don't currently seem to be
> happening. It was mentioned on IRC that D 2.000 don't seem to have got much
> praise yet, and as far as I can see, there are good reasons for this. D is
> having it's biggest change yet, and the community in general seems to have
> more or less qualms with the current implementation. 

I think the implementation is all right, I just think the syntax needs to be reconsidered. Personally, I think the whole const-final-invariant thing is quite a bit nicer than any other implementation I've seen: being able to mark an object as invariant makes writing threadsafe code a lot easier. If there was a way to mark a class/struct as "invariant after being constructed," then it'd be unbeatable.