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 <tseit...@icloud.com> wrote: > > > Am 21.11.2017 um 02:39 schrieb Kelvin Ma via swift-evolution < > swift-evolution@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@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
