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
