Getting the const-correctness of Object sorted once and for all

[Christophe]

Chad J , dans le message (digitalmars.D:167472), a écrit :
> On 05/15/2012 02:49 PM, Christophe wrote:
>> Chad J , dans le message (digitalmars.D:167461), a écrit :
>>> An idea I thought of is to introduce a method local declaration that
>>> allows a method to access instance-specific-state that isn't accessible
>>> to the rest of the class:
>>
>> It is not good for caching results, since the cache often has to be
>> erased when the object is modified.
> 
> I did outline a way to invalidate caches with this.

I was a bit fast on my post, but it cannot work: Something has to be 
modified both normally by a non-const function to invalidate the cache, 
and exceptionally by the const function to set the cache.


Two remarks about people trying to solve the const problem:

 - People trying to modify a const value by using holes like delegates 
and inner classes might as well cast away const.

 - People trying to associate mutable members to a const object might as 
well ask for a @mutable keyword to have members that stays mutable even 
if the object is const (and remove power to class with @mutable members, 
such as the possibility to be immutable, have strongly pure methods, 
etc.). It will have the same effect as other proposed work arround, but 
at least it is easy to understand how it works and won't cripple the 
langage with too many awkward rules.

After all, D is a mutli-paradigm programming langage. It should not 
force programmers to use hard constness. Better use as clean as possible 
@mutable data than complicated workarrounds.