On 28/11/10 3:45 PM, Jonathan M Davis wrote:
Oh, I agree that the lack of logical const is a problem, but allowing for
mutable member variables within a const object is a whole in the const system,
and Walter, at least, is convinced that doing so is completely broken.
Mutable member variables are only a hole in the const system if the
const system is overly strict about what const is. 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.
You mentioned having an external cache of Matrix determinants. One way
to view mutable would be to see it as an automation and optimisation of
this external cache (optimised because it stores the cache right inside
the object, rather than in a slow external hash table).
Certainly, because of immutable in D, I have to agree that in the general case,
it wouldn't work. Without immutable, you could presumably get something similar
to what C++ has (if you could ever get Walter to go for it), but once you have
immutable, that doesn't work anymore, since anything that's const could actually
be immutable, and then it's _definitely_ impossible to change it.
Then perhaps what is needed is an intermediate level of immutability.
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 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.
