How to break const

[Timon Gehr]

On 06/20/2012 04:56 PM, Christophe Travert wrote:
> Timon Gehr , dans le message (digitalmars.D:170313), a écrit :
>>> 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.
>>
> The spec, by saying it is necessary to maintain immutability, has its
> own reasons. In reality, it is not purely necessary to maintain
> immutability, as you say, but it is necessary to maintain immutability

if(true && ... )

> AND the benefit of purity,

As I said, 'const pure' with mutable/const arguments loses guarantees.
purity does not lose its benefits.

> AND the integrity of the whole spec, which is
> based on the assumption that const is transitive.
>

The integrity of the spec cannot be maintained because it does not have one.

>>> Making it not transitive would break the mutable<   const<  immutable design.
>>
>> What is this '<' relation ?
>
> I meant that const is somewhere between mutable and immutable.
> Also, mutable variable can contains const and immutable data, const
> variable can contain immutable data, but no mutable data (meaning:
> mutable through this reference). Subparts of a reference can increase
> the protection level of the data, but not decrease it.
>

If 'const' is about 'protection' then you are straight into
interpretation 1. This is not what I was discussing.


>>> 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.
>
> Making exception in the langage is dangerous because you can have
> surprising results when interacting with other exception. Give some spec
> explaining how your opaque delegate works,

It is not an exception. What do you think is the exception?

> and someone will find a hole one day.
>

Before the language adapts the change, its correctness could be
formally proven.

> I can't think of a way of implementing opaque delegates without a hole
> inside, or without loosing most of the point of immutability and purity.
> If you do, please share.
>

Delegates cannot be opaque as much as any other data structure. But
they have the property that their data is only accessible via a
pointer to a fully type checked function. This facilitates reasoning
about what is and what is not valid for them.