<html><head><meta http-equiv="content-type" content="text/html; charset=utf-8"></head><body dir="auto"><div></div><div><br></div><div><br>Am 21.11.2017 um 02:39 schrieb Kelvin Ma via swift-evolution <<a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a>>:<br><br></div><blockquote type="cite"><div><div dir="ltr"><div><div>when <a href="https://github.com/apple/swift-evolution/blob/master/proposals/0185-synthesize-equatable-hashable.md">SE-185</a> went through swift evolution, it was agreed that the <a href="https://www.mail-archive.com/swift-evolution@swift.org/msg26162.html">next logical step</a> 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 <span style="font-family:monospace,monospace">Comparable</span> to the other two protocols because there is precedent in the language from <a href="https://github.com/apple/swift-evolution/blob/master/proposals/0015-tuple-comparison-operators.md">SE-15</a> that tuple comparison is something that makes sense to write.<br><br></div>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 <br></div><div><br></div><div><span style="font-family:monospace,monospace">let lattice = Dictionary<(Int, Int, Int), AssociatedValue>() .</span><br></div><div><br></div><div>the commonly suggested “workaround”, which is to “upgrade” the tuple to a struct is problematic for two reasons:</div><div><br></div><div>1. it defeats the purpose of having tuples in the language</div><div><br></div><div>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.<br></div></div>
</div></blockquote><div><br></div>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.<div><br></div><div><div><span style="background-color: rgba(255, 255, 255, 0);">struct Point {</span></div><div><span style="background-color: rgba(255, 255, 255, 0);"> func distance(to point: Point) -> Vector</span></div><div><span style="background-color: rgba(255, 255, 255, 0);"> func offsetBy(_ offset: Vector) -> Point</span></div><div><span style="background-color: rgba(255, 255, 255, 0);">}</span></div><div><br></div><div>Notwithstanding this disagreement I too think that EHC conformance for tuples would be useful. </div><div><br></div><div><span style="background-color: rgba(255, 255, 255, 0);">-Thorsten</span></div><div><span style="background-color: rgba(255, 255, 255, 0);"><br></span></div><div><span style="background-color: rgba(255, 255, 255, 0);"><br></span></div><blockquote type="cite"><div><span>_______________________________________________</span><br><span>swift-evolution mailing list</span><br><span><a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a></span><br><span><a href="https://lists.swift.org/mailman/listinfo/swift-evolution">https://lists.swift.org/mailman/listinfo/swift-evolution</a></span><br></div></blockquote></div></body></html>