On Fri, Mar 16, 2012 at 05:01:16PM +1100, Daniel Murphy wrote:
> How close would this put us to not needing toHash in typeinfo at all?
[...]

Is there anything besides AA's that uses TypeInfo.getHash? If not, this will completely eliminate the need for it.

This is one of my motivations for doing this -- util.rt.hash.hashOf is already pure, and I have a pull request to make it usable in CTFE. Once we eliminate TypeInfo.getHash, we can finally clean up the const/pure/etc. mess caused by the current dependency on it. That in turn will allow most AA methods to be nothrow pure const @safe (or at the very least nothrow pure @safe; the only AA method that can't be nothrow is opIndex). Currently I have quite a few methods with "nothrow pure" commented out, because of the mess in the various overrides of TypeInfo.getHash.


T

-- 
To err is human; to forgive is not our policy. -- Samuel Adler

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