How to break const

[deadalnix]

Le 20/06/2012 16:21, Timon Gehr a écrit :
> 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.

What about conversion from/to immutable ?