If performance is the only reasons to have a separate method, perhaps it might make sense to have a note about this in the isLessThanOrEqualTo description, and provide a default implementation that calls down on isLess and isEqual.
Nicola On Tue, Apr 26, 2016 at 4:59 PM, Stephen Canon <[email protected]> wrote: > On Apr 26, 2016, at 10:03 AM, Nicola Salmoria via swift-evolution < > [email protected]> wrote: > > > it should be enough to do > > func <= <T: FloatingPoint>(lhs: T, rhs: T) -> Bool > { > return lhs.isLess(than: rhs) || lhs.isEqual(to: rhs) > } > > Or is there some case of x, y where (x <= y) is true but (x < y) and (x == > y) are both false? > > > No, these are always equivalent. > > However, there is a problem with this approach: the compiler knows about > the built-in floating-point types (Float, Double, Float80) and their > aliases (CGFloat, etc) and can fuse the two comparisons into a single > hardware operation. However, for soft-float types, without a > lessThanOrEqual method, there is no single comparison that the compiler > could fuse these to. > > In some cases, if they are simple enough, the compiler may be able to > actually fuse the bodies of the two comparison operations, but we can’t > reasonably depend on that happening or even being possible in all cases. > So for performance, it’s important that there be an actual less than or > equal to method. > > – Steve >
_______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
