> On 25 Jul 2016, at 18:51, Björn Forster <[email protected]> wrote: > > Could you please explain for someone as simple minded as me why there is (or > has to be) a difference in the implementation of <, <= and >, >=? > Sorry, but I don't get into my head why there is/has to be a preference for > one side. Could you or someone else point out (in the proposal) why there is > a need/what is the reason for this? > I assume that this might not be obvious to some other people on the first > look, too.
The reason is two-fold: Firstly, and most importantly, because we want the law of antisymmetry (that `a < b` iff `b > a`, and likewise for ≤ and ≥) to hold even in the presence of strange types. Turning only one operator of every such pair into customisation points makes it essentially impossible to break that law. Secondly, because we want to minimise the surface area of Comparable to keep the API as simple as possible. The drawback of my design is that while it manages to alleviate many subtleties of IEEE-754, it also contains many member functions (essentially all but `<=>`) which should not be customised for most types in practice. — Pyry
_______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
