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

[Jordan Rose]

[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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160421/edcf6e3b/attachment.html>