Inherited const when you need to mutate

[deadalnix]

On 11/07/2012 02:20, Timon Gehr wrote:
> On 07/11/2012 01:57 AM, Walter Bright wrote:
>> On 7/10/2012 4:16 PM, Timon Gehr wrote:
>>> Const is stronger than what is required to bridge the gap between
>>> mutable and immutable. It guarantees that a reference cannot be used to
>>> mutate the receiver regardless of whether or not the receiver is
>>> immutable underneath. That is unnecessary as far as immutable is
>>> concerned. It only needs to guarantee that the receiver does not change
>>> if it is immutable underneath.
>>
>> If you have a const function that accepts both mutable and immutable
>> args, then that function *by definition* cannot tell if it received
>> mutable or immutable args.
>>
>
> I understand. The trick is to disallow creating immutable instances of a
> class which is allowed to mutate the receiver in const methods.
> This is essentially your proposal with the casts, but it is type safe.
>
> This removes the 'const' guarantees, but 'immutable' stays
> unaffected. Furthermore, functions with closures are type checked at
> their creation site and may violate const-transitivity without affecting
> 'immutable'.
>

It is interesting. But is does transfers the constraint on const on 
constraint of not being const for children.

This isn't a free win, and I'm not sure it worth it.