[dmd-internals] AssociativeArray in druntime should go before the next release

[Daniel Murphy]

On Sat, Feb 4, 2012 at 2:31 AM, Steve Schveighoffer <schveiguy at yahoo.com> wrote:
> As someone who's actually developed a hashmap in D2, I'd agree with Don that there are still some things that cannot fully implement how builtin AA's work (most glaring example is lack of constructor that takes literal values).  But it's better to have this part of the system pluggable.  Not only does it allow one to utilize D's power to work on something intrinsic like this, but it makes things simpler to understand from a maintenance perspective.  Not to mention, I could make AA's into dcollections hashmaps with some simple changes to the runtime :)
>
>
> I agree with the approach below except for 2 things:
>
> 1. D1 AA's used a tree to handle bucket collisions, I don't think we should roll back that far (not sure what the state of D1 AAs are today).

Nowhere near that far.  All that's getting rolled back is the
AssociativeArray templated struct in object.d, which basically just
forwards to the druntime functions (_aaGet, _aaRehash, etc)  The most
prominent effect of this struct is the multitude of AA ice bugs.

> 2. This conversion:  [a:b, c:d] -->  AALiteral([a, c], [b, d]) should *NOT* use the heap for the two array literals.  I'm not sure how you can declare AALiteral such that this doesn't happen, but this needs to be solved.
>

It's not about how AALiteral is declared, it's how the compiler calls
it.  For a lot of druntime calls it currently does something along the
lines of:
Key[dim] keys;
... store the keys ...
Value[dim] values;
... store the values ...
aa = AAliteral(key, value);

We'll need to define an interface, but that's just the point - the
current half-language/half-runtime solution doesn't have this.