http://d.puremagic.com/issues/show_bug.cgi?id=9771
--- Comment #1 from Jonathan M Davis 2013-03-21 00:05:52
PDT ---
Related:
opEquals: issue# 9769
opCmp: issue# 9770
toString: issue# 9772
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving
http://d.puremagic.com/issues/show_bug.cgi?id=9771
hst...@quickfur.ath.cx changed:
What|Removed |Added
CC||hst...@quickfur.ath.cx
--- Com
http://d.puremagic.com/issues/show_bug.cgi?id=9771
--- Comment #3 from Jonathan M Davis 2013-03-22 19:09:41
PDT ---
> This probably can't be implemented until we replace AA's with a library
> template
I figured that that was probably the case, and that will certainly slow this
down, but it st
http://d.puremagic.com/issues/show_bug.cgi?id=9771
--- Comment #4 from hst...@quickfur.ath.cx 2013-03-22 19:28:25 PDT ---
I wouldn't go as far as using introspection to make a default toHash, but I
think there's value in providing a default toHash for classes that just hashes
the object's addres
http://d.puremagic.com/issues/show_bug.cgi?id=9771
--- Comment #5 from hst...@quickfur.ath.cx 2013-03-22 19:30:38 PDT ---
Also, if the default behaviour of == for structs is to do bitwise comparison,
then I think it justifies defining toHash for structs that just hashes the bit
representation of
http://d.puremagic.com/issues/show_bug.cgi?id=9771
--- Comment #6 from hst...@quickfur.ath.cx 2013-03-22 19:32:00 PDT ---
P.S. I meant *default* toHash for structs, of course. Obviously the user should
be able to override the default behaviour (hence the usefulness of using UFCS
for toHash, sinc
http://d.puremagic.com/issues/show_bug.cgi?id=9771
--- Comment #7 from Jonathan M Davis 2013-03-22 20:29:03
PDT ---
Whether it makes sense or not to use the bit representation for hashing depends
on the struct, as according TDPL, bitwise comparison is _not_ supposed to be
the default for struc
http://d.puremagic.com/issues/show_bug.cgi?id=9771
Jacob Carlborg changed:
What|Removed |Added
CC||d...@me.com
--- Comment #8 from Jacob
http://d.puremagic.com/issues/show_bug.cgi?id=9771
--- Comment #9 from hst...@quickfur.ath.cx 2013-03-23 08:20:16 PDT ---
(In reply to comment #8)
> I think that will conflict with having a moving garbage collector.
Good point, maybe the correct approach is to hash the respective hashes of each
http://d.puremagic.com/issues/show_bug.cgi?id=9771
--- Comment #10 from Jacob Carlborg 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.
--
C
http://d.puremagic.com/issues/show_bug.cgi?id=9771
--- Comment #11 from Jonathan M Davis 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 de
http://d.puremagic.com/issues/show_bug.cgi?id=9771
--- Comment #12 from Jacob Carlborg 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
http://d.puremagic.com/issues/show_bug.cgi?id=9771
--- Comment #13 from Jonathan M Davis 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 cl
http://d.puremagic.com/issues/show_bug.cgi?id=9771
Martin Nowak changed:
What|Removed |Added
CC||c...@dawg.eu
--- Comment #14 from Marti
http://d.puremagic.com/issues/show_bug.cgi?id=9771
--- Comment #15 from Jonathan M Davis 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/
https://issues.dlang.org/show_bug.cgi?id=9771
Iain Buclaw changed:
What|Removed |Added
Priority|P2 |P4
--
16 matches
Mail list logo
