[swift-evolution] [pitch] Comparison Reform

[Jonathan Hull]

I still like the ordering of floats defined in this proposal best (and think we should use it), but I imagine that there are other types which are almost (but not quite) comparable as well. Would there be any utility in having a ‘PartialComparable’ protocol that defined a single method:

	func compare(_:)->ComparisonResult?

That is, it is just like our compare, but it returns nil if two values can’t be meaningfully compared.  It would force you to deal with the cases where the comparison didn’t make sense, and handle it in a reasonable way in your code. (e.g. filtering those values out, or sticking them at the end).

You can think of it as failable compare...

Thanks,
Jon


> On Apr 13, 2017, at 1:17 PM, Ben Cohen via swift-evolution <swift-evolution at swift.org> wrote:
> PartialComparable
> 
> PartialComparable would essentially just be Comparable without any stated ordering requirements, that Comparable extends to provide ordering requirements. This would be a protocol that standard IEEE comparison could satisfy, but in the absence of total ordering requirements, PartialComparable is effectively useless. Either everyone would consume PartialComparable (to accept floats) or Comparable (to have reasonable behaviour).
> 
> The Rust community adopted this strategy to little benefit. The Rust libs team has frequently considered removing the distinction, but hasn’t because doing it backwards compatibly would be complicated. Also because merging the two would just lead to the problems Swift has today.
> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20170413/d7bf485d/attachment.html>