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

[Kelvin Ma]

a good idea on paper, a disastrous one in practice. What happens if every
geometry library declares their own Point type?

On Tue, Nov 21, 2017 at 1:15 AM, Thorsten Seitz <tseitz42 at icloud.com> wrote:

>
>
> Am 21.11.2017 um 02:39 schrieb Kelvin Ma via swift-evolution <
> swift-evolution at swift.org>:
>
> 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.
>
>
> Actually I don't think that tuples should be used for points and vectors
> at all, because I prefer to differentiate these two concepts which requires
> nominal types, e.g.
>
> struct Point {
>     func distance(to point: Point) -> Vector
>     func offsetBy(_ offset: Vector) -> Point
> }
>
> Notwithstanding this disagreement I too think that EHC conformance for
> tuples would be useful.
>
> -Thorsten
>
>
> _______________________________________________
> 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/20171121/b38e3466/attachment.html>