> Am 21.11.2017 um 07:32 schrieb Kelvin Ma <kelvin1...@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 <tseit...@icloud.com> wrote:
>>
>>
>>> Am 21.11.2017 um 02:39 schrieb Kelvin Ma via swift-evolution
>>> <swift-evolution@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@swift.org
>>> https://lists.swift.org/mailman/listinfo/swift-evolution
>
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution
