How to break const

Christophe Travert travert at phare.normalesup.org
Wed Jun 20 07:56:00 PDT 2012


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 
AND the benefit of purity, AND the integrity of the whole spec, which is 
based on the assumption that const is transitive.

>> 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.

>> 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, and someone will find a hole 
one day.

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.



More information about the Digitalmars-d mailing list