> On Apr 23, 2016, at 8:53 PM, Brent Royal-Gordon via swift-evolution
> <[email protected]> wrote:
>
> 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.
There are concrete conversions between all built in float types. Those aren’t
going away. Are you saying that you want init(_ value: Float) etc to be
protocol requirements?
>> public protocol FloatingPoint: Comparable, IntegerLiteralConvertible {
>> public protocol BinaryFloatingPoint: FloatingPoint, FloatLiteralConvertible {
>
> Any reason why FloatLiteralConvertible isn't on FloatingPoint?
It doesn’t make sense for non-radix-2 types; you would change bases multiple
times.
>> 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?)
Correct, the free functions will use these.
>> 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`.)
There’s lots of concern, and very few suggestions of anything better. The only
thing that seems workable is maybe `isLessThanOrEqualTo(_:)`, which is
inconsistent with the other comparisons, but maybe that’s the right thing to do
anyway.
>> 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.
Heterogeneous comparisons have an unambiguous result type and correct result.
Heterogeneous arithmetic does not (at least, not in all cases), so it’s a more
difficult language design problem.
>> 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)
Yup, that’s exactly right. I’ll add a note.
>> * 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.
Thanks for the feedback!
– Steve
_______________________________________________
swift-evolution mailing list
[email protected]
https://lists.swift.org/mailman/listinfo/swift-evolution
