How to break const

[Timon Gehr]

On 06/20/2012 03:13 PM, Christophe Travert wrote:
> Timon Gehr , dans le message (digitalmars.D:170296), a écrit :
>> On 06/20/2012 01:36 PM, Christophe Travert wrote:
>>> Timon Gehr , dans le message (digitalmars.D:170288), a écrit :
>>>> On 06/20/2012 09:16 AM, deadalnix wrote:
>>>>> Le 19/06/2012 17:49, Timon Gehr a écrit :
>>>>>>
>>>>>> The question is, what the meaning of 'const' references should be:
>>>>>>
>>>>>> 1. data cannot be changed transitively through the reference
>>>>>>
>>>>>> 2. the reference can reference both 'const' and 'immutable' data and
>>>>>> 'immutable' data can transitively not be changed through the
>>>>>> reference.
>>>>>>
>>>>>>
>>>>>> 1. requires transitive const for delegate context pointers, 2. does not.
>>>>>>
>>>>>
>>>>> No, 2. require 1., even if the initialization is broken.
>>>>>
>>>>> class Foo {
>>>>>        void delegate() dg;
>>>>>
>>>>>        this(immutable void delegate() dg) immutable {
>>>>>            thid.dg = dg;
>>>>>        }
>>>>> }
>>>>>
>>>>> Now, as delegate doesn't carry the constness of its context, an
>>>>> immutable instance of Foo can refers to something that isn't immutable.
>>>>
>>>> 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
>>
>> The conclusion regarding transitivity, given interpretation 2., is that
>> 'const' needs to be transitive _if_ it is actually 'immutable'.
>
> OK, I understand what you mean. I think this behavior is dangerous. You
> have to add rules to make sure B is not violated. I am not sure this is
> worth it.
>

No additional rules necessary, only loosening of existing rules. (in
the obvious design, not in how the compiler implements it.)

>>> If you apply different rules to const and to immutable, you are breaking
>>> the consistency of the langage.
>>>
>>
>> Certainly not. This is like saying that applying different rules to
>> 'const' and mutable is breaking the consistency of the language.
>> mutable is not transitive.
>
> OK, that was not the right argument. Const is transitive according to
> the spec.

IIRC the spec is based on the claim that this is necessary in order to
maintain immutability guarantees, so this is irrelevant for discussions
relating to the alternative interpretation.

> Making it not transitive would break the mutable<  const< immutable design.

What is this '<' relation ?

> You're trying to make an exception for data hidden
> behind a delegate, which is a dangerous thing.
>

I understand the implications. There is nothing dangerous about it.