[swift-evolution] Refining SE-0185: Should providing a custom == suppress the default hashValue?

[Tony Allevato]

On Fri, Dec 15, 2017 at 6:41 PM Howard Lovatt <howard.lovatt at gmail.com>
wrote:

> I think that is an advanced use, rather than a common use. I would prefer
> that to be something you manually code.
>

But why? Why should implementing a subset of fields for hashValue require a
developer to also manually implement == when the default synthesized
version would be perfectly fine? The relationship between Equatable and
Hashable does not go both ways.

In fact, requiring that they do so is *more* error prone because now
they're being forced to implement something that the compiler would have
otherwise generated for them.



>
>
> -- Howard.
>
> On 16 Dec 2017, at 7:08 am, Tony Allevato <tony.allevato at gmail.com> wrote:
>
>
>
> On Fri, Dec 15, 2017 at 11:39 AM Howard Lovatt via swift-evolution <
> swift-evolution at 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 at 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 at 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 at swift.org
>> >> https://lists.swift.org/mailman/listinfo/swift-evolution
>> > _______________________________________________
>> > swift-evolution mailing list
>> > swift-evolution at swift.org
>> > https://lists.swift.org/mailman/listinfo/swift-evolution
>> _______________________________________________
>> swift-evolution mailing list
>> swift-evolution at swift.org
>> https://lists.swift.org/mailman/listinfo/swift-evolution
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20171216/0c8c6f65/attachment.html>