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

[Thorsten Seitz]

> Am 21.11.2017 um 02:39 schrieb Kelvin Ma via swift-evolution <swift-evolution at swift.org>:
> 
> when SE-185 went through swift evolution, it was agreed that the next logical step 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 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/45b8767c/attachment.html>