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
_______________________________________________
swift-evolution mailing list
[email protected]
https://lists.swift.org/mailman/listinfo/swift-evolution
