@regexident has a long-standing proposal about how to do hashing better that would address this:
https://gist.github.com/regexident/1b8e84974da2243e5199e760508d2d25 <https://gist.github.com/regexident/1b8e84974da2243e5199e760508d2d25> Dave > On Dec 15, 2017, at 2:04 PM, T.J. Usiyan via swift-evolution > <swift-evolution@swift.org> wrote: > > Can we provide a 'standard' method/function that can be used to combine > ordered hash values (`[Int] -> Int`)? That could make manually implementing > `hashValue` less burdensome. > > TJ > > On Fri, Dec 15, 2017 at 12:08 PM, Tony Allevato via swift-evolution > <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote: > > > On Fri, Dec 15, 2017 at 11:39 AM Howard Lovatt via swift-evolution > <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote: > +1 > I think the simple solution of if you provide either == or hashValue you have > to provide both is the best approach. Good catch of this bug. > -- Howard. > > That would be a significant usability hit to a common use case. There are > times where a value is composed of N fields where N is large-ish, and > equality is dependent on the values of all N fields but the hash value only > needs to be "good enough" by considering some subset of those fields (to make > computing it more efficient). > > That still satisfies the related relationship between == and hashValue, but a > user wanting to explicitly implement a more efficient hashValue should *not* > necessarily be required to explicitly write the same == that would be > synthesized for them in that case. > > > > > On 16 Dec 2017, at 6:24 am, Daniel Duan via swift-evolution > > <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote: > > > > +1. The proposal wasn’t explicit enough to have either supported or be > > against this IMO. It’s a sensible thing to spell out. > > > > Daniel Duan > > Sent from my iPhone > > > >> On Dec 15, 2017, at 9:58 AM, Joe Groff via swift-evolution > >> <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote: > >> > >> SE-0185 is awesome, and brings the long-awaited ability for the compiler > >> to provide a default implementation of `==` and `hashValue` when you don't > >> provide one yourself. Doug and I were talking the other day and thought of > >> a potential pitfall: what should happen if you provide a manual > >> implementation of `==` without also manually writing your own `hashValue`? > >> It's highly likely that the default implementation of `hashValue` will be > >> inconsistent with `==` and therefore invalid in a situation like this: > >> > >> struct Foo: Hashable { > >> // This property is "part of the value" > >> var involvedInEquality: Int > >> // This property isn't; maybe it's a cache or something like that > >> var notInvolvedInEquality: Int > >> > >> static func ==(a: Foo, b: Foo) -> Bool { > >> return a.involvedInEquality == b.involvedInEquality > >> } > >> } > >> > >> As currently implemented, the compiler will still give `Foo` the default > >> hashValue implementation, which will use both of `Foo`'s properties to > >> compute the hash, even though `==` only tests one. This could be > >> potentially dangerous. Should we suppress the default hashValue derivation > >> when an explicit == implementation is provided? > >> > >> -Joe > >> _______________________________________________ > >> swift-evolution mailing list > >> swift-evolution@swift.org <mailto:swift-evolution@swift.org> > >> https://lists.swift.org/mailman/listinfo/swift-evolution > >> <https://lists.swift.org/mailman/listinfo/swift-evolution> > > _______________________________________________ > > swift-evolution mailing list > > swift-evolution@swift.org <mailto:swift-evolution@swift.org> > > https://lists.swift.org/mailman/listinfo/swift-evolution > > <https://lists.swift.org/mailman/listinfo/swift-evolution> > _______________________________________________ > swift-evolution mailing list > swift-evolution@swift.org <mailto:swift-evolution@swift.org> > https://lists.swift.org/mailman/listinfo/swift-evolution > <https://lists.swift.org/mailman/listinfo/swift-evolution> > > _______________________________________________ > swift-evolution mailing list > swift-evolution@swift.org <mailto:swift-evolution@swift.org> > https://lists.swift.org/mailman/listinfo/swift-evolution > <https://lists.swift.org/mailman/listinfo/swift-evolution> > > > _______________________________________________ > swift-evolution mailing list > swift-evolution@swift.org > https://lists.swift.org/mailman/listinfo/swift-evolution
_______________________________________________ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution
