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. These methods would be supplied in the new AA module (which sorta makes sense, since it's really only AA's that ever want to compute hashes of stuff anyway, so toHash should be provided by the AA module, just like array.popFront & friends are provided by std.range), and will provide a uniform interface for generic code to simply call "toHash" on *any* type of x instead of the current shenanigans involving typeid().

In fact, we can even supply, via UFCS, toHash templates instantiable for *all* structs and classes (doing a naïve hash on the binary representation of the object). Since UFCS only kicks in if an in-struct or in-class method can't be found, this effectively provides a "default" toHash that can be "overridden" if the struct/class declares its own version of it.

If we implement this, it will become possible to initialize immutable AA's at compile-time, that is, generate the AA Slots, their references to each other, etc., at compile-time, and stick them in the static data segment in the object code, so there will be zero runtime overhead.

What do y'all think about this idea?


T

-- 
"Computer Science is no more about computers than astronomy is about telescopes." -- E.W. Dijkstra

On Thursday, 15 March 2012 at 23:53:26 UTC, H. S. Teoh wrote:
> In fact, we can even supply, via UFCS, toHash templates instantiable for *all* structs and classes (doing a naïve hash on the binary
> representation of the object).

For a project, I've created something that generated toHash,
opCmp, opEquals and toString methods for a variety of structs. I
needed it to work with tagged unions, so you could declare a
special method that indicated which fields to
hash/compare/stringize.

https://github.com/CyberShadow/RABCDAsm/blob/master/autodata.d

The code may be more complicated than currently necessary, since
it was initially written for D1.

How close would this put us to not needing toHash in typeinfo at all?