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