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.
