How to break const

[Don Clugston]

On 18/06/12 17:00, Artur Skawina wrote:
> On 06/18/12 16:41, deadalnix wrote:
>> Le 18/06/2012 16:28, Artur Skawina a écrit :
>>> It's fine, if you view a delegate as opaque.
>>>
>>
>> No it isn't. You cannot ensure transitivity anywhere. This have obvious, and severe drawback for concurrent programing (implicit sharing is back) and GC performances (GC can eb crazy fast when it come to transitive immutable data, see OCaml's GC performances for instance).
>>
>>> 'this' being const does not preclude accessing the object that 'this'
>>> points to via another, mutable, reference.
>>>
>>> Consider the alternative - you'd have to forbid storing any delegate
>>> with a non-const non-value argument inside any object.
>
> So how would you like to handle this? And, no, allowing only the cases
> that /can/ be statically checked is not ok - it would result in black
> magic - delegates would be accepted or not depending on the contents
> of the object (think templates and composition).
>
>>> And "breaking" const would then _still_ be possible and trivial.
>>>
>>
>> No, and your example don't demonstrate that in any way. Transitivity is maintained in the example below, because g isn't a member of s, and if it were, then the example would break at compile time.
>
> The word "breaking" is in quotes for a reason. Const is not an immutability
> guarantee. If you treat delegates as opaque then there's no practical
> difference between using them or accessing the data via another external
> reference.
>
>> purity is another beast altogether.
>
> D's "weak pure" can help; I just don't like the redefinition of the term
> "purity"; another name for "weak purity" would be better.

So would I. Can you think of one?
It was the best name I could come up with, given that the 'pure' was the 
keyword.
We want a word that means 'no hidden state'.