On 11/28/10 1:01 PM, Peter Alexander wrote:
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.
Mutable is a disaster with read-write locks. Without mutable, you could
surround a C++ object with a read-write lock and count on const member
functions being lockable with read locks. With mutable, all that
guarantee is out the window.
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.
This is probably not going to get a lot of community traction :o).
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.
I think you are able to implement memoization in a library. At any rate,
I think "X is unusable because I can't use it with obscure idiom Y" is a
dangerous state of mind. Of course memoization is more or less obscure
depending on whom you ask, but objective speaking it's simply not that
frequent, and definitely not something you can't achieve in a variety of
ways.
Andrei
