On Tue, Mar 13, 2012 at 09:30:45PM -0500, Andrei Alexandrescu wrote: > On 3/13/12 7:54 PM, H. S. Teoh wrote: > >Hi all, > > > >My AA implementation is slowly inching closer to being ready to > >replace aaA.d. > > Great! This will need compiler restructuring, and in fact offers the > perfect opportunity for it. I suggest you to post your implementation > here for review first, and assume only the minimal lowerings from the > compiler.
Currently I have it as a struct that implements AA functionality without needing special support from the compiler (i.e., as a template library). The only thing that needs compiler support is AA literals and internal mapping between V[K] and AssociativeArray!(K,V) for nicer syntax and error messages. I didn't do anything fancy with the implementation, just used the same algorithms as the current aaA.d, the idea being that fancy stuff can be added later once we have successfully extricated AA's from internal compiler dependencies. The current code is already nicer in that it no longer needs the void* casts and typeinfo's now that key/value types are directly accessible. This will allow us to address some fundamental issues with aaA.d such as key/value types that require deep traversal of references (the current implementation of AA.toHash is broken partly because of this). Of course, performance issues also need to be addressed eventually, such as possible optimizations when key/value types have no external references, in which case some operations can use byte-level representations instead. But IMO this should be postponed till later; the main thing right now is to fix up the compiler. Once AA's are completely in object.d, optimizations and other fixes/improvements will be much easier. > Here's something that I thinks we should have: > > int[string] aa; > char[] b; > ... > aa[b] = 42; > > The implementation should be clever enough to work, and only duplicate > the string if it wasn't already present. [...] Hmm, this is something nice to have. I guess get() and opIndex*() should allow any type that is comparable with the key type? Now that the implementation is in a template, this should be much easier to do. :) But while we're at it, one thing that I'd like to see is that AA key types should be *implicitly* immutable. It makes no sense for AA keys to be mutable, and it's syntactically painful to keep typing stuff like string[immutable(int)[]]. Especially when mutable key types *never* make sense anyway. So why not translate string[int[]] into string[immutable(int)[]] implicitly? Thoughts? T -- INTEL = Only half of "intelligence".