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

I’m skeptical that your use case is common enough to justify leaving open the glaring bug magnet that started this thread. Could you give an example of a common occurrence where it would be a significant improvement to explicitly write a *less precise* hash function that’s only “good enough”

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

Those are valid concerns for hashing algorithms in general, but there's no connection between that and a statement that an explicitly implemented hashValue should also require an explicitly implemented ==. Requiring that certainly doesn't make it less likely that people will run into the problem

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

On Fri, Dec 15, 2017 at 6:41 PM Howard Lovatt 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

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

In Java they have simple to use var arg library functions that equate and hash values. I have written similar in my own code. Something like: func equate(_ e0: (T0, T0), _ e1: (T1, T1)) -> Bool where T0: Equatable, T1: Equatable { return e0.0 == e0.1 && e1.0 == e1.1 }

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

I think that is an advanced use, rather than a common use. I would prefer that to be something you manually code. -- Howard. > On 16 Dec 2017, at 7:08 am, Tony Allevato wrote: > > > >> On Fri, Dec 15, 2017 at 11:39 AM Howard Lovatt via swift-evolution >>

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

On Fri, Dec 15, 2017 at 6:58 PM, 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

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

@regexident has a long-standing proposal about how to do hashing better that would address this: https://gist.github.com/regexident/1b8e84974da2243e5199e760508d2d25 Dave > On Dec 15, 2017, at 2:04 PM, T.J. Usiyan via

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

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> wrote: > > > On

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

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

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

+1. I think there is a reasonable general principle at work here: the semantics of the implementation of a refining protocol depend upon the semantics of the implementation of a refined protocol. For this reason the compiler should not synthesize an implementation for a refining protocol

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

> On Dec 15, 2017, at 11:39 AM, Howard Lovatt via swift-evolution > 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. That would certainly be a simple

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

+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. > On 16 Dec 2017, at 6:24 am, Daniel Duan via swift-evolution > wrote: > > +1. The proposal wasn’t explicit

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

+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 > wrote: > > SE-0185 is awesome, and brings the

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

> On Dec 15, 2017, at 10:08 AM, Wallacy wrote: > > Is possible to make the compile check what is used inside of == and then > provide the hash value? And if compile cannot check (for whatever reason) > what’s properties is used inside == then raise a compile error? That

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

+1, that sounds like a reasonable way to handle that situation. This is another one of those pitfalls that could be mitigated with something like the "transient" attribute that was discussed in earlier discussion threads, but that's really about a slightly different problem statement—it would let

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

Is possible to make the compile check what is used inside of == and then provide the hash value? And if compile cannot check (for whatever reason) what’s properties is used inside == then raise a compile error? Em sex, 15 de dez de 2017 às 15:58, Joe Groff via swift-evolution <

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

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