Fully transitive const is not necessary

[Steven Schveighoffer]

"Janice Caron" wrote
> On 02/04/2008, Steven Schveighoffer wrote:
>> Sure.  Now I'll restate what I have been stating in these terms:  globby
>>  classes are EQUIVALENT to logically const classes (or "muty" classes as 
>> you
>>  call them).  Since they are equivalent, and we can have globby classes 
>> today
>>  with transitive const, so what is the problem with allowing muty 
>> classes?
>>  How would this break the const system?
>
> Great! I understood. (I disagree, but I understood).
>
> OK, in what sense are globby classes equivalent to muty classes?
> Because, you see, I don't think they are. When you modify a global
> variable, you are modifying something /else/, something other than the
> class. In no way can this be said to be violating transitive const.
> But when you modify a mutable variable in C++ (and I have to use C++
> as my example, because it's not legal in D), then you /have/ violated
> transitive const. That difference makes them seem not equivalent to
> me.

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 {...}
}

Assume the ellipsis' are implementations that get and set a globally (or 
statically) stored x.

Please don't point out that I can't do the same operations on x in the 
globby version because it is not a data member, this is a limitation of the 
D language, and I can always make functions that do the operation needed. 
The essential proof is that I can re-assign x.

There is no semantic difference.  Both have an x member that is mutable when 
the instance is const.  The globby version can be supported with today's 
const regime and compiler, why not also allow the muty version.

As a challenge, come up with a muty type that cannot be implemented as a 
globby type in the context of constancy/invariance.

-Steve