Fully transitive const is not necessary

[Steven Schveighoffer]

"Janice Caron" wrote
> On 02/04/2008, Steven Schveighoffer wrote:
>> globby classes are equivalent to muty classes because in both cases I am
>>  storing information outside the const scope.  In globby classes, I'm 
>> storing
>>  it in a global AA that has an element for each instance of the class 
>> that's
>>  created.  In muty classes, I'm storing it in a member variable with the
>>  class.  In all cases, it's not considered to be a state of the class, 
>> it's
>>  just that for muty classes, I'm storing it with the class (and reaping 
>> the
>>  benefits of not having to manage a globally stored AA).
>>
>>  I can prove that muty classes are equivalent to globby classes:
>>
>>  class muty
>>  {
>>     mutable X x;
>>  }
>>
>>  is equivalent to
>>  class globby
>>  {
>>    X x() const {...}
>>    X x(X newvalue) const {...}
>>  }
>
> So you're mimicking mutable fields with a global AA. Gotcha.
>
> There are several problems with this, including:
> (1) the global variable is visible to at least the entire module, so
> something else might modify it when you're not looking.

Who cares?  I am in charge of my module, it's not possible for another 
author to change the AA in a way that I do not define.  If anything, this is 
an argument FOR logical const so I can have the compiler help me prevent 
this :)

> (2) are we really sure that modifying an AA is an atomic operation? I'm 
> not.

I am really sure that modifying an AA is not an atomic operation, but that 
has no bearing on the proof.  Setting x in the mutable version is also not 
atomic.  They are still equivalent.

> It's also worth mentioning that you won't be able to modify global
> variables in a pure function, so the ability to mimic mutable member
> variables is lost at that point.

Again, if logical const were allowed, pure functions would not be able to 
modify the mutable portions of classes, so this is not a difference between 
muty and globby.

I think I may have not explained my opinion correctly on pure functions.  I 
believe transitive invariance is required for enforcable pure functions.  In 
order to enforce that, the compiler should be able to tell what is supposed 
to be invariant and what is not.  Having logical const be a possibility does 
not prevent this, because the compiler can just force the pure function not 
to use the mutable portions of the class/struct.

If mutable member variables were allowed, they would have the same 
restrictions for pure functions as any other external mutable variable.

-Steve