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

Thorsten Seitz tseitz42 at icloud.com
Tue Nov 21 10:12:28 CST 2017



> Am 21.11.2017 um 07:32 schrieb Kelvin Ma <kelvin13ma at gmail.com>:
> 
> a good idea on paper, a disastrous one in practice. What happens if every geometry library declares their own Point type?

Well, if I really had the need to use several geometry libraries at once I would have to convert, of course. But I prefer that to the loss of type safety where I could confuse points, vectors and probably more, like colors or whatever else ends up as a tuple...

-Thorsten

> 
> 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 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/2c95edb6/attachment.html>


More information about the swift-evolution mailing list