I would say it is an advanced use because it is an optimisation and in addition
an optimisation that requires a lot of knowledge of the fields to be certain
that a reduced hash is going to be good enough.
The optimisation doesn’t have a great history, for example in Java they used to
hash only the 1st 6 characters of a string. However this was exploited in
denial of service attacks that generated a vast number of strings with the same
hash value, i.e same 1st 6 characters, that then overwhelmed the dictionary
(map in Java) used in the web server software to store logins.
So it wouldn’t be something I would encourage people to do or even worse do by
accident.
-- Howard.
> On 16 Dec 2017, at 3:36 pm, Tony Allevato <tony.allev...@gmail.com> wrote:
>
>
>
>> On Fri, Dec 15, 2017 at 6:41 PM Howard Lovatt <howard.lov...@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.allev...@gmail.com> wrote:
>>>
>>>
>>>
>>>> On Fri, Dec 15, 2017 at 11:39 AM Howard Lovatt via swift-evolution
>>>> <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> 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> 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
>>>> >> 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
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution
