> On Dec 22, 2015, at 10:39 AM, Guillaume Lessard <[email protected]> > wrote: > > I wholeheartedly support the Equatable (==) portion of this proposal. > I’m quite negative about the Comparable portion; it doesn’t really make sense. > > The justification for making Tuples comparable pretty much consists of > hand-waving. > Why should (0,3,4) be smaller than (0,5,0)? Beats me. > Why would it be the other way around? Also beats me.
So that there’s a default sort order, e.g. in case you want to unique them. Lexicographical ordering by component is the natural choice, IMO. > I can vaguely see the utility of Comparable when I squint, but the actual > behaviour would require extensive documentation with caveats about it not > really making any sense. To overload an operator with a clear meaning with a > behaviour with a wishy-washy definition is a bad idea. > > > * Is the problem being addressed significant enough to warrant a change to > Swift? > > Yes for Equatable. > No for Comparable. > > > * Does this proposal fit well with the feel and direction of Swift? > > Yes for Equatable. > No for Comparable. > > > * If you have you used other languages or libraries with a similar feature, > how do you feel that this proposal compares to those? > > I have used Mathematics during an extensive education in Physics and > Engineering, at the end of which I escaped with a Ph.D. from a major > institution. > > Making arbitrary Tuples Equatable when possible makes sense. > Making them Comparable absolutely does not. > > Comparability is domain-specific. The standard library cannot know what an > arbitrary Tuple means. That’s why we have versions of sort et. al. that take custom comparison closures. > * How much effort did you put into your review? A glance, a quick reading, or > an in-depth study? > > I drew upon my experience. While I feel it’s on solid footing, I would > hesitate to call it an in-depth study. > > > Finally, I would like to note that I would support a free-standing function > with a clear name that does the same thing as the proposed overloads of the > comparison operator. > > Sincerely, > Guillaume Lessard > -Dave _______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
