On Tue, Dec 22, 2015, at 10:39 AM, Guillaume Lessard via swift-evolution 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.
You're proposing that there isn't a clear reason for it to behave the way it
is, but you haven't given any justification for this claim. I say there is in
fact a clear reason, and that reason is that lexicographical order is a pretty
common assumption.
> 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.
It makes sense in any situation where lexicographical comparisons is
appropriate, which I would wager covers most of the times where tuple
comparisons in general make sense. Not only that, but providing an easy way to
invoke lexicographical comparison using tuples allows people to invoke this
behavior easily on arbitrary data when they need it.
It was mentioned in the old proposal thread that providing an equality operator
on tuples makes it easy to implement equality on structs by just comparing
tuples constructed from the struct fields. Comparison operators have the same
benefit. For example:
struct Version: Comparable {
let major: Int
let minor: Int
let patch: Int
}
func ==(lhs: Version, rhs: Version) -> Bool {
return (lhs.major, lhs.minor, lhs.patch) == (rhs.major, rhs.minor,
rhs.patch)
}
func <(lhs: Version, rhs: Version) -> Bool {
return (lhs.major, lhs.minor, lhs.patch) < (rhs.major, rhs.minor, rhs.patch)
}
> * 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.
The standard library cannot know this for equality either. But you still think
that makes sense. There's plenty of ways to construct tuples where the meaning
of equality of the whole is different than the meaning of equality of parts.
And if this distinction is important to capture, you're free to define a struct
instead of using a tuple, as you can then provide whatever specific notion of
equality (or comparability) you want.
I guess the overall question is, given that lexicographical ordering is a very
common ordering, what harm is there in providing a lexicographical ordering
operation on tuples? If it doesn't make sense for the tuple in question, then
just don't try and compare it. Heck, we provide a comparison operator on
strings even though the particular comparison it implements isn't always what
you want (for example, it's case-sensitive and you may want case-insensitive
comparison) but nobody is arguing that strings shouldn't be comparable.
-Kevin Ballard
> * 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
_______________________________________________
swift-evolution mailing list
[email protected]
https://lists.swift.org/mailman/listinfo/swift-evolution
