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.