[swift-evolution] [swift-evolution-announce] [Review] SE-0067: Enhanced Floating Point Protocols

[Brent Royal-Gordon]

A few things…

First, something absent: I'm a little bit concerned by the act that there's no means to convert between different concrete FloatingPoint types. Something like the IntMax mechanism in Swift 2's IntegerType might be useful, though there may be good reasons not to do that.

> public protocol FloatingPoint: Comparable, IntegerLiteralConvertible {
> public protocol BinaryFloatingPoint: FloatingPoint, FloatLiteralConvertible {

Any reason why FloatLiteralConvertible isn't on FloatingPoint?

>   prefix func +(x: Self) -> Self

Does this actually do anything, or is it a no-op? If the latter, should it just be a free function rather than part of the protocol? Or maybe even part of the literal syntax that can't be applied to variables at all?

>   static func minimum(x: Self, _ y: Self) -> Self
>   static func maximum(x: Self, _ y: Self) -> Self
>   static func minimumMagnitude(x: Self, _ y: Self) -> Self
>   static func maximumMagnitude(x: Self, _ y: Self) -> Self

These all take two operands, but I can't think of a reason for that. Might they be better off as variadic? (Or is the "implementation hook" comment meant to indicate that the variadic form of the `max` free function will use these calls?)

>   func isEqual(to other: Self) -> Bool
>   func isLess(than other: Self) -> Bool
>   func isLessThanOrEqual(to other: Self) -> Bool

I'm still not sure why these are methods instead of operators.

(I also share others' concern about the argument label on `isLessThanOrEqual`.)

>   func isUnordered(with other: Self) -> Bool
>   func isTotallyOrdered(with other: Self) -> Bool

I think these features should be folded into Comparable, but I'll start a different thread about that. For the moment, these seem fine.

>   func isEqual<Other: BinaryFloatingPoint>(to other: Other) -> Bool
>   func isLess<Other: BinaryFloatingPoint>(than other: Other) -> Bool
>   func isLessThanOrEqual<Other: BinaryFloatingPoint>(to other: Other) -> Bool
>   func isUnordered<Other: BinaryFloatingPoint>(with other: Other) -> Bool
>   func isTotallyOrdered<Other: BinaryFloatingPoint>(with other: Other) -> Bool

Can you provide some color on these? Loosening the typing in this way is quite unusual in Swift; you're not doing it for arithmetic operators, for instance.

>   init(nan payload: Self.RawSignificand, signaling: Bool)


The discussion doesn't mention why this isn't part of the protocol. Any commentary? (I'm guessing it's "you need to know the type anyway to do anything useful with the payload", but I'm not sure, and it's useful to document the reasons for these sorts of decisions)

> 	* What is your evaluation of the proposal?

I think it's a huge improvement.

> 	* Is the problem being addressed significant enough to warrant a change to Swift?

Yes. The current floating-point protocols are inadequate.

> 	* Does this proposal fit well with the feel and direction of Swift?

Yes.

> 	* If you have you used other languages or libraries with a similar feature, how do you feel that this proposal compares to those?

I don't have much experience with floating-point abstractions of this sort, but as far as the end-user APIs are concerned, I really like these APIs.

> 	* How much effort did you put into your review? A glance, a quick reading, or an in-depth study?

Participated in the previous round of discussion as well as this one.

-- 
Brent Royal-Gordon
Architechies