http://d.puremagic.com/issues/show_bug.cgi?id=9771
--- Comment #11 from Jonathan M Davis <[email protected]> 2013-03-23 12:09:46 PDT --- > Jonathan didn't seem to like that idea. Given that the default opEquals is supposed to compare each member variable using ==, I think that it would make good sense for the default toHash to call toHash on each member variable and generate a new hash from those. What doesn't make sense is blindly using reflection to go over all of member variables and generating hashes for them regardless of how they're implemented. Some folks in the newsgroup liked the idea of using external functions to use reflection to go through a type's member variables recursively to generate a hash, and given how opEquals and toHash are related, I think that that's an extremely bad idea, and that's the main thing that I'm objecting to. But if we're talking about a default-generated toHash that's only generated when opEquals is default-generated, then we know some things about what opEquals looks like and can generate a toHash which correctly corresponds to it, which would generally mean calling toHash on each member variable and generating a new hash from that - though if the compiler decided that it could do a bitwise comparison of the struct (e.g. because all of the member variables were integral types), then generating a hash in a similar manner would make sense. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email ------- You are receiving this mail because: -------
