Unified toHash() for all native types

[H. S. Teoh]

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