digitalmars.D - Unified toHash() for all native types
- H. S. Teoh (28/28) Mar 15 2012 I'm working on making AA literals work with my new AA implementation,
- Vladimir Panteleev (9/13) Mar 15 2012 For a project, I've created something that generated toHash,
- Daniel Murphy (1/1) Mar 15 2012 How close would this put us to not needing toHash in typeinfo at all?
- H. S. Teoh (16/17) Mar 16 2012 [...]
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
Mar 15 2012
"Vladimir Panteleev" <vladimir thecybershadow.net> 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.
Mar 15 2012
How close would this put us to not needing toHash in typeinfo at all?
Mar 15 2012
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
Mar 16 2012