[swift-evolution] Universal Equatability, Hashability, and Comparability

Tony Allevato allevato at google.com
Tue May 24 14:50:06 CDT 2016


Absolutely—I would expect that if the user provided their own
implementation of `==` for a particular type, it would override (rather,
suppress) the compiler-provided one; the same for hashValue.

On Tue, May 24, 2016 at 11:50 AM Jan E. Schotsman via swift-evolution <
swift-evolution at swift.org> wrote:

>
> On May 24, 2016, at 6:50 PM, Tony Allevato wrote:
>
> On the one hand, getting the conformance implicitly matches how
> RawRepresentable is already treated, and makes getting the conformance zero
> effort. On the other hand, it makes error handling trickier: if you add a
> non-Equatable/non-Hashable field or associated value to a struct/enum, all
> of your call sites break. (I guess they would even if you declared the
> conformance, but at least there you'd also get the "Type does not conform
> to Equatable/Hashable" error at the struct/enum itself, and the compiler
> could even potentially flag the offending field/associated value that's
> causing the conformance to fail.) Thoughts?
>
>
> I would like to have the option to override the compiler-provided equality
> etc.
> For example, exclude one field from the definition of equality.
> It would be nice if the default implementation would be available inside
> the definition of a custom implementation so you can base your custom
> implementation on that.
>
> Jan E.
>
> _______________________________________________
> 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/20160524/3168182b/attachment.html>


More information about the swift-evolution mailing list