On Mon, Sep 16, 2013 at 10:38:58PM +0200, Namespace wrote: > >D is not only about arrays. > It's a big plus. ;) > > > >[1] Obviously, not a practical short term option for the existing D2 > >language. That's probably clear from the context, and the question > >was meant to be rhetorical -- but it could actually be done and would > >make sense; it's just not a change that would make enough of a > >difference on its own; the cost would be to high. > > Why to high? Too much compiler magic or dmd internal dependences?
I disagree that it's too high. It just needs *somebody* with the right knowledge about DMD internals (and enough free time on their hands >:-)) to pull it off. The problem with the current AA implementation is that it's schizophrenically split across DMD, aaA.d, and object.di. Martin Nowak recently cleaned it up somewhat (removed the horrible code duplication between aaA.d and object.di that used to be there) but fundamental issues remain, a major cause of which is the fact that aaA.d operates on typeinfo's rather than the direct types (this isn't a problem in and of itself, but the problem is that *only* AA keys have the benefit of their typeinfo's being available to AA functions, which means AA *values* that require non-trivial postblits and other such things are fundamentally broken in horrible ways). Moreover, DMD still retains way too much knowledge about AA internals, so sometimes it gets mapped to struct AssociativeArray, sometimes directly mapped to aaA.d, and sometimes a buggy inconsistent mixture of both. And the code that emits these different schizophrenic parts are sprinkled all over different unrelated parts of DMD, making any cleanup attempt rather challenging, to say the least. And of course, any non-correspondence between any of these parts means yet another AA bug waiting to happen. Cleaning up this mess once and for all will unquestionably do a world of good to D. T -- You are only young once, but you can stay immature indefinitely. -- azephrahel