On Thu, Mar 15, 2012 at 04:55:09PM -0700, H. S. Teoh wrote: > I'm working on making AA literals work with my new AA implementation, > and ran into a major roadblock with using CTFE to compute AA literals: > currently built-in types like arrays require TypeInfo in order to > compute the hash, but TypeInfo's are not accessible during CTFE. > > Since it's a lot of work (arguably too much work) to make TypeInfo's > usable during CTFE, I'm thinking of making use of UFCS to declare > toHash() methods for *all* native types. [...]
Alright, I've starting a git branch to experiment with this idea: https://github.com/quickfur/New-AA-implementation/tree/ctfelit I've gotten it to the point where all current AA unittests work (but full coverage of all built-in types is not quite there yet). Getting rid of the calls to typeinfo.getHash() already has the very nice side-effect of making almost all AA methods that should be pure nothrow @safe, actually pure nothrow @safe. (Due to the mess in the current getHash(), toString(), etc., getHash is impure and throwing, even though the hash computation itself never throws, so anything that uses getHash can't be pure nothrow.) I've also written a bunch of unittests to ensure that the new toHash() methods return the same value as typeinfo.getHash(). (OT: My favorite line in the unittests is: checkNumericArrays!(byte, ubyte, short, ushort, int, uint, float, double, real)(); which checks T[], const(T)[], and immutable(T)[] for all the above types, and is a testament to just how much D's variadic templates r0x0rs.) Anyway. One weird thing I came across was the fact that char[] and immutable(char)[] (aka string) have a different hash computation than every other array (including const(char)[], strangely enough). What's the rationale for this strange special case? Is it safe to get rid of this inconsistency and make all arrays use rt.util.hash.hashOf()? T -- "Real programmers can write assembly code in any language. :-)" -- Larry Wall