How to break const

[deadalnix]

Le 20/06/2012 10:18, Christophe Travert a écrit :
> deadalnix , dans le message (digitalmars.D:170262), a écrit :
>> Once again, this is inconsistent with how purity is defined elsewhere.
>>
>>> I'm all for fixing this hole - it's just that the proposed "fix" would
>>> have consequences, which can't simply be ignored.
>>>
>>
>> They are not ignored, but it seems you don't clearly understand the
>> implications and the big picture.
>
> Let me stress that argument: It has been said in several places in the
> newsgroup that D had many features that work right, but now problems
> emerge when feature interacts with each other. That is why consistency
> in the langage design is *very* important.
>
> Implementing delegates properly with constness of the context pointer,
> and a consistent pure attribute is a way that garanties that delegates
> interacts finely with all other feature (constness, purity, etc.):
> delegates are implementable has classique structures with an opApply
> like I showed in a post in this thread. There is no black magic (1), an
> thus delegates are guaranted not add any hole in the langage: delegates
> are only a very convenient way to do what you can do with a context
> pointer and a function pointer.
>
> (1) there is still a little bit of magic: closure makes automatic heap
> allocation of normally stack variables. Since you could do that
> explicitely, this is no big problem. The only way to make this magic
> disappear is to make heap allocation of normally stack variables legal
> in other cases, which would cover another big hole in the langage but
> this is too big a change in the langage to be accepted for the moment.
>

What is the conclusion here ?