Logical const

[Andrei Alexandrescu]

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