http://d.puremagic.com/issues/show_bug.cgi?id=9771



--- Comment #10 from Jacob Carlborg <doob@me.com> 2013-03-23 08:33:35 PDT ---
(In reply to comment #9)
> Good point, maybe the correct approach is to hash the respective hashes of each member of the class?

Jonathan didn't seem to like that idea.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------

http://d.puremagic.com/issues/show_bug.cgi?id=9771



--- Comment #11 from Jonathan M Davis <jmdavisProg@gmx.com> 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: -------

http://d.puremagic.com/issues/show_bug.cgi?id=9771



--- Comment #12 from Jacob Carlborg <doob@me.com> 2013-03-23 15:29:36 PDT ---
(In reply to comment #11)

> 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.

I see, so only when opEquals is default generated.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------

http://d.puremagic.com/issues/show_bug.cgi?id=9771



--- Comment #13 from Jonathan M Davis <jmdavisProg@gmx.com> 2013-03-23 19:12:53 PDT ---
> I see, so only when opEquals is default generated.

Yes. We could provide helper functions or mixins to make it easier to write hash functions if you define opEquals (or on classes which won't have any kind of default opEquals - let alone the useless one that they have now), but as soon as opEquals has been defined by the programmer, it has to be up to the programmer to define toHash correctly, as in order for hashing to work correctly, every object which is equal must have the same hash. And if the programmer defined opEquals, then the compiler will no longer have enough information to define a toHash which guarantees that all equal objects will have the same hash.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------

http://d.puremagic.com/issues/show_bug.cgi?id=9771


Martin Nowak <code@dawg.eu> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |code@dawg.eu


--- Comment #14 from Martin Nowak <code@dawg.eu> 2013-06-03 08:15:21 PDT ---
(In reply to comment #2)
> This probably can't be implemented until we replace AA's with a library template, since otherwise it would make it impossible for e.g. classes to be used as AA keys.

That very simple to solve, let the compiler pass two functions (hash, equals) to the AA implementation instead of RTTI.

> Once we have the library type, though, we can probably make use of UFCS to provide default implementations of toHash for all types.

I would not want to bet that this will happen.
The current situation where the AA is partly implemented in the compiler and in
the runtime is unfortunate to say the least.
Also performance-wise a generic AA implementation will never be on par with one
that's suited for a special purpose. So it makes a lot of sense to have a lean
builtin implementation and provide more configurable ones in std.container.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------

http://d.puremagic.com/issues/show_bug.cgi?id=9771



--- Comment #15 from Jonathan M Davis <jmdavisProg@gmx.com> 2013-10-13 16:17:28 PDT ---
Relevant discussion on how to transition away from having these functions on Object (the thread got broken up a bit - probably by the mailman bug):

http://forum.dlang.org/post/mailman.214.1369617617.13711.digitalmars-d@puremagic.com http://forum.dlang.org/post/mailman.280.1369712394.13711.digitalmars-d@puremagic.com

The key suggestion is to change the compiler so that those 4 functions can be free functions in object_.d, similar to how the compiler already does special stuff for == rather than simply calling Object's opEquals.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------