On 11/28/10 9:45 AM, 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.
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.
From what I can tell of the current situation, either you make something const
and guarantee that it's actually constant (which would tend to mean that you're
_not_ going to get things like caching - which honestly, is something that most
objects don't need anyway - though obviously there are those where it can help a
great deal), or you maintain the state that you want outside the object and
manipulate that. I believe that someone else suggested have an associative array
as a cache outside of the object. That way, you could grab the value from there
instead. And if you had to calculate a new value, you'd be free to stick it in
the external associate array (or whatever you wanted to use to hold the cache).
Regardless, with how D works, in the general case, if you want something to be
const, you're going to have to actually let it be const. That means no logical
const unless you play games with stuff outside of the object (which
unfortunately, throws purity out the window). It's certainly a problem, but it's
not a problem with most objects, and it's not like we're going to talk Walter
into using mutable like in D. And with immutable in the language, you couldn't
do it anyway.
So, yes it's a problem. But as far as I can tell, it's one that we're stuck
with.
The library solution to logical constness would gravitate around a union
with a const (or immutable) and a regular field of the same type:
union {
T before;
const T after;
}
Andrei
