[swift-evolution] Synthesizing Equatable, Hashable, and Comparable for tuple types

[Kelvin Ma]

when SE-185
<https://github.com/apple/swift-evolution/blob/master/proposals/0185-synthesize-equatable-hashable.md>
went through swift evolution, it was agreed that the next logical step
<https://www.mail-archive.com/swift-evolution@swift.org/msg26162.html> is
synthesizing these conformances for tuple types, though it was left out of
the original proposal to avoid mission creep. I think now is the time to
start thinking about this. i’m also tacking on Comparable to the other two
protocols because there is precedent in the language from SE-15
<https://github.com/apple/swift-evolution/blob/master/proposals/0015-tuple-comparison-operators.md>
that tuple comparison is something that makes sense to write.

EHC conformance is even more important for tuples than it is for structs
because tuples effectively have no workaround whereas in structs, you could
just manually implement the conformance. this is especially relevant in
graphics and scientific contexts where tuples are used to represent color
values and points in 2D or 3D space. today you still can’t do things like

let lattice = Dictionary<(Int, Int, Int), AssociatedValue>() .

the commonly suggested “workaround”, which is to “upgrade” the tuple to a
struct is problematic for two reasons:

1. it defeats the purpose of having tuples in the language

2. tuples are a logical currency type for commonly used types like points
and vectors. If every library defined its own custom point/vector types we
would soon (already?) have a nightmare situation where no geometry/graphics
library would be compatible with any other geometry/graphics library, at
least not without a lot of annoying, let alone wasteful swizzling and
manual conversion routines in the main application.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20171120/cb80cb27/attachment.html>