Logical const

[Andrei Alexandrescu]

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