[Proposal:
https://github.com/apple/swift-evolution/blob/master/proposals/0067-floating-point-protocols.md
<https://github.com/apple/swift-evolution/blob/master/proposals/0067-floating-point-protocols.md>]
This is super impressive. I do have several bits I’m uncomfortable with,
however. I’ll try to separate that into “semantic” and “naming” sections.
Semantic
static var radix: Int { get }
Does it ever make sense to have a model type that allows different instances to
have different radices?
Is there an algorithm that makes use of a model’s radix, or is this just in
here for “completeness”?
/// A signaling NaN (not-a-number).
@warn_unused_result
static func signalingNaN: Self { get }
I’m not sure it really makes sense for a Bignum / APFloat type to support such
a value. But really I think this is just underspecified. What does it mean, in
terms of this protocol and its uses, for a NaN to be signaling? Is it just a
specific “color" of NaN, with no semantic requirements other than being
distinguishable?
(Also, is ‘signalingNan.isNan’ true? I assume so but since ’nan’ is implied to
be a non-signaling NaN I’m not sure anymore.)
var signBit: Bool { get }
Unlike Chris, I’m strongly against this property as it stands. You should not
be able to write “if someValue.signBit”; a bit is not a boolean value.
(Citation: "Uses of Boolean methods and properties should read as assertions
about the receiver
<https://swift.org/documentation/api-design-guidelines/#strive-for-fluent-usage>.”)
I’d be okay with Greg’s idea of changing the type to an enum. I’d also be okay
with renaming this to a predicate, whatever the name ends up being.
(“isSignBitSet”, “isSignNegative”, etc.)
var exponent: Int { get }
Nitpick: it’s probably worth noting in the doc comment that this is the
unbiased exponent value.
Also, does it matter that this is insufficient for bignums, which may have an
exponent of greater than `sizeof(Int.self)` bits? (This is also a concern for a
number of members of BinaryFloatingPoint, like ‘significantBitCount'.)
Naming
On “NaN” vs. “Nan”: I’m not convinced that ignoring the case is the right way
to go here. IMHO the clearest lowercase form is “nan” and the clearest
capitalized form is “NaN”.
The current draft API guidelines
<https://swift.org/documentation/api-design-guidelines/#general-conventions>
don’t cover this case, but if I were to add something for this, I’d say “when a
word is normally written with mixed case, the lowercase form should be
fully-lowercased if the first letter is naturally uppercase, and the
capitalized form should have the first letter uppercased only.” That rule
produces “iPhone/IPhone”, “next/NeXT”, and “nan/NaN”. (The “if the first letter
is naturally uppercase” could be thrown out as well.)
On 'isLessThanOrEqual(to:)’: I agree with Xiaodi that the argument label is
problematic here. I think the problem is that we have two prepositions that
apply to the argument, and “pick the second one” leaves the base name feeling
unbalanced. (Remember that we allow referring to a method by its basename alone
when using it as a function value.)
On 'isTotallyOrdered(with:)’: I lost track of who said it, but I agree that
this sounds like it’s “!isUnordered(with: other)”. The only name that’s coming
to mind is ‘isTotallyOrderedBefore(_:)’, which isn’t great.
On ‘binade’: At first I thought this was a confusing term and there had to be a
better one, but now I think it’s an “if you don’t know what this is, you don’t
need to use it” case. :-)
Jordan_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution
