Replacing AA's in druntime

[H. S. Teoh]

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".