Standalone AA implementation ready for review (Was: Re: 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.

Alright, I've finished the basic functionality of my AA implementation.
I still haven't solved that problem with using suffixless string
literals to index X[dstring], so you'll have to write aa["abc"d] instead
of just aa["abc"]. But I thought I should post my code now so that
people can take a look at it:

	https://github.com/quickfur/New-AA-implementation/blob/master/newAA.d

Currently, this code is still standalone, not integrated with druntime
yet.  Since that will require compiler changes and is potentially a very
big change, I've decided to polish up the standalone version as much as
possible before attempting druntime integration.

There are still some outstanding issues:

- As mentioned above, wstring or dstring keys (in fact any array keys
  with literals that doesn't default to the key type) need an explicit
  suffix when indexing with literals. I haven't figured out how to make
  this work yet.  At the very least, wstring and dstring needs to
  support suffixless key literals; it would be nice if a general
  solution could be found for all array-typed keys.

- Declaring an AA with non-const array keys will cause reams and reams
  of compile errors. I'm not *too* worried about this at the moment
  since it doesn't make sense to have non-const AA keys anyway. I'm also
  seriously considering forcing *all* AA keys to be immutable, in which
  case this will become a non-issue.

- Some code (most notably that table of primes that I hoisted from
  aaA.d) may need to be refactored to prevent excessive code bloat when
  the AA template is instantiated.

- Array literals don't work yet (requires compiler support).

- X[Y] syntax doesn't work yet (requires druntime integration & compiler
  support); you have to explicitly declare AssociativeArray!(Y,X).

- The use of typeid.getHash. This is probably OK, except that it forces
  a lot of AA methods not to be pure nothrow @safe. It would also be
  nice if there was a uniform syntax for getting the hash of a type
  without going through typeid (may be more efficient?).

- I haven't stress-tested AA performance yet. (Any volunteers? ;-)) Some
  improvement in this area will probably be needed, though we may not
  need to address that until this is ready for druntime integration.

- (There's also some temporary development-only code, syntactic sugar
  aliases, that shouldn't end up in object_.d -- those will be removed
  when I'm ready for druntime integration. There's also some code that
  needs a bit of cleanup.)

In spite of its flaws, this implementation already addresses quite a few
AA-related issues in the bugtracker, as verified by a bunch of unittests
(search for "Issue" in the code).

Comments? Flames? ;-) Pull requests?? :-D


T

-- 
It is the quality rather than the quantity that matters. -- Lucius Annaeus Seneca