"H. S. Teoh" <hst...@quickfur.ath.cx> wrote in message news:mailman.176.1331147910.4860.digitalmar...@puremagic.com... > On Sun, Mar 04, 2012 at 07:31:49AM +0100, Martin Nowak wrote: >> Wasn't the latest proposal that we add a working AA implementation to >> the runtime and switch the compiler after that has settled? > > Is somebody working on that? If not, I may take a crack at doing it. > > And by runtime you mean object_.d, right? aaA.d is already part of > druntime, from what I understand. :-) > > > T > > -- > If it breaks, you get to keep both pieces. -- Software disclaimer notice
I was the one that recently tried to get AAs rolled back to the D1 implemenation (unsuccessfully) but I'm not working on a reimplementation. The closed pull requests are sitting on github if you'd like to take a look at them. For it to be 'fixed', AAs need to be able to do all the things they can do now, including producing error messages with V[K] instead of AssociativeArray!(K, V), magic initialization and the same reference semantics. They also need to _work_ in ctfe, either because the implementation is available and ctfeable, or because the calls get translated late enough that the interpreter can pick out the IndexExps/DotIdExps and treat them specially. At the moment I'm leaning towards doing the translations in the glue layer, and using ufcs for everything else, but whatever works. There's a thread on the internals mailing list that lists some of the issues with the current implementation.