How to break const

[Timon Gehr]

On 06/20/2012 02:38 PM, deadalnix wrote:
> Le 20/06/2012 13:58, Timon Gehr a écrit :
>>>> Clarification: 'const' means 'const'. No other qualifiers.
>>>>
>>>> There is no 'const' in that example code. 'immutable' obviously
>>>> needs to
>>>> be transitive regardless of the particular interpretation of 'const'.
>>>>
>>> const means: maybe immutable.
>>
>> Or maybe mutable. Therefore, interpretation '2.'
>>
>>> Thus const needs to be transitive too.
>>
>> Wrong. This is the (A==>B) ==> (B==>A) fallacy, where
>>
>> A: 'const' is transitive
>> B: 'const' references cannot modify 'immutable' data
>>
>
> I understand the difference. It can change the legality of some calls,
> that is true (and probably it is better).

None is strictly better than the other. Interpretation 2. gains some 
flexibility in respect to interpretation 1., but it loses some 'const
pure' guarantees.

It is a matter of how these two orthogonal concerns are weighted
against each other. (Ideally, there would be one distinct qualifier for
each of the interpretations. :o) )

> But it doesn't change the need
> for a frame pointer's qualifier (mandatory to ensure immutability
> transitivity).
>
> To benefit of the extra freedom granted by B, what could be the casts
> safely allowed on the delegate ? I understand your point, but fail to
> find any way to make it work in practice.

It works if implicit conversions from 'R delegate(A)' to
'R delegate(A) const' are allowed, as well as looking up an
'R delegate(A) in a const receiver object.