> David Sweeris wrote:
>
> I'm starting to come down from me earlier +1... Floor and ceiling are more
> functions than properties of a number, aren't they?
I agree with that. Having used various math libraries for decades now, I'd find
it odd to find these as members of a floating-point type, especially so for the
suggested in-place mutating variants. These tend to be function-like constructs
(or various kinds of brackets) in mathematics too, just like trigonometric
functions.
But since do we need these in the FloatingPoint protocol for generic
algorithms, I'd suggest defining them as static members, and keeping
state-of-art names (or close) where possible:
protocol FloatingPoint {
static func floor(_ value: Self) -> Self
static func ceiling(_ value: Self) -> Self
static func truncate(_ value: Self) -> Self
static func round(_ value: Self) -> Self
}
The top-level functions can them simply delegate to these counterparts:
func floor<T : FloatingPoint>(_ value: T) -> T {
return .floor(value)
}
— Pyry
_______________________________________________
swift-evolution mailing list
[email protected]
https://lists.swift.org/mailman/listinfo/swift-evolution
