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. 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. * 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 _______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
