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.
