How to break const

Christophe Travert travert at phare.normalesup.org
Wed Jun 20 01:18:19 PDT 2012


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.

-- 
Christophe


More information about the Digitalmars-d mailing list