Peter Alexander wrote:
In C++, I view
mutable as an extension to the const system that allows one to define
member variables that are attached to an object, but ultimately do not
affect the observable state of the object.
There is no way a C++ compiler can statically verify this. It's pure convention.
immutable - Data will never, ever change, through any reference.
const - Data will never change through this reference.
newlevel - Data will never logically change through this reference.
The problem with newlevel is (to repeat myself) it is unverifiable.
The idea here is that you would use this newlevel normally (like you use
const normally) and only use this new const when you actually desire
strict const-ness e.g. when you are using the resource concurrently.
I'll happily admit that it's starting to get on the complex side, but as
far as I'm concerned, const in D as it is now is simply unusable. I will
happily write const correct code, but not when it means giving up the
possibility of writing memoized functions.
On the other hand, the C++ notion of const makes it impossible to have nice
things like verifiably pure functions.
You can write memoized functions in D, you just can't label them as const.
You'll be relying on convention. Memoized (logically const) functions are not
verifiable in C++, either, so you are not technically worse off.