Standalone AA implementation ready for review (Was: Re: Replacing AA's in druntime)

[H. S. Teoh]

On Thu, Mar 15, 2012 at 05:02:06PM +0100, Don Clugston wrote:
[...]
> This is good, and very, very important. Do *not* make any attempt at
> compiler integration until it is *completely* ready.
> 
> This includes AA literals. They need to be accepted somehow. The
> compiler will give you syntax sugar and *nothing* more.
> One possibility might be to accept a pair of array literals,
> representing keys and values.

Alright, I've made a preliminary implementation of AA literals as a
function that constructs an AA given an array of keys and and an array
of values (just like the current aaA.d implementation).  The changes
have been pushed to github:

	https://github.com/quickfur/New-AA-implementation/commit/c272909626f09829f333467499996250c2a1e8d2

Currently this function is a static member; I'm thinking maybe it might
be better to make it an external template function instead. That way, we
only need the compiler to do array type inference for the input arrays,
and the function will use the inferred types to determine the AA
key/value types.


> Possibly it should call a CTFE function to convert them into some
> other form?

I do intend to do more with AA literals, including making them
compileable into object code directly (using static struct instances and
mixins), but that will be more involved, and will require implementing
toHash() for all native types using UFCS, that I proposed in another
thread. A quick hand-crafted test earlier today showed that it *can* be
done; it's just a matter of getting the various pieces in place.


T

-- 
Curiosity kills the cat. Moral: don't be the cat.