Inherited const when you need to mutate

[Christophe Travert]

Andrei Alexandrescu , dans le message (digitalmars.D:171828), a écrit :
> On 7/10/12 5:19 PM, H. S. Teoh wrote:
> 
> There is value in immutable objects that has been well discussed, which 
> is incompatible with logical constness. We can change the language such 
> as: a given type X has the option to declare "I want logical const and 
> for that I'm giving up the possibility of creating immutable(X)". That 
> keeps things proper for everybody - immutable still has the strong 
> properties we know and love, and such types can actually use logical const.
> 
> A number of refinements are as always possible.

I think this is a good idea, but for classes, inheritance is an issue. 

Example:

class A
{
  int a;
  int compute() const pure { return a; }
  final int fun() const pure
  {
    a.compute; // optimised out by the compiler
    return a.compute;
  }
}

class B : A
{
  @mutable int b;
  override int compute() const pure
  {
     if(!b) b = longComputation(a);
     // a += 1; // error, a is bitwise-const
     return b; // mutating and returning a mutable part at the 
               // programmer's risk
  }
}

A.compute is bitwise const. However B.compute is logical const. A.fun is 
bitwise const, and can be optimised. But that is no longer true with a B 
instance. However, the compiler must be able to make those 
optimizations, otherwise all the power of const for any non final object 
is lost, because someone may derive a logical const class. This means 
the programmer is *responsible* for creating a logical const-behavior. 
This is a serious issue.

Given the system-programming aspect of D, I would say the programmer 
should be allowed to do such a thing, taking the risk to have an 
undefined behavior. But with great caution. At least, it will be less 
dangerous than casting away const. Just providing a way to make it 
impossible to create an immutable instance of some classes would make it 
less dangerous to cast away constness.

-- 
Christophe