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

[Timon Gehr]

On 05/16/2012 10:17 AM, Christophe wrote:
> [...] @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.
>

I think this is a very sane proposal, (the important points are stated 
in parens) because 'const' alone does not give any useful guarantees. 
The essential guarantee is that an immutable object attached to a const 
reference cannot be mutated through it.

An issue is that fully 'const pure' methods would lose their guarantees 
when passed a mutable object, unless const member functions that mutate 
@mutable members of the receiver object cannot be pure. This rule would 
disqualify the solution for what is discussed in the OP.

Leaving the rule out would imply that the currently valid code 
transformation:

int foo(const pure A){ }

A a = ...;

int x=foo(a), y=foo(a)
=>
int x=foo(a), y=x;

would become incorrect in the general case. The proposal trades off 
'const' guarantees against mutable/immutable interoperability. I would 
be willing to take that.