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

[Xiaodi Wu]

 * What is your evaluation of the proposal?

+1 in intent. Specifics require further refinement. For example:

Internal inconsistencies in capitalization:
* `signalingNaN` but `isSignalingNan` and `isNan`

Parameter labels, or whatever they're called now, do not reflect newly
adopted Swift syntax in SE-0046:
* `static func maximum(x: Self, _ y: Self) -> Self` should be `static
func maximum(_ x: Self, _ y: Self) -> Self`, etc.

Infelicitous use of prepositions to conform superficially to new
naming guidelines:
* `isEqual(to:)` is fine, but for consistency there's
`isLessThanOrEqual(to:)`, which is not fine, because the preposition
"to" applies only to "equal" and not to "less than"

Since `adding(_:)` is instead now an operator in the current version
of the proposal, could comparison functions also be operators only?

Incorrect nomenclature in an attempt to correct previously misleading
nomenclature:
* `leastMagnitude` should be `leastPositive` or `minPositive`, because
magnitudes can be zero: it's bonkers that
`Double.minimumMagnitude(0.0, Double.leastMagnitude) <
Double.leastMagnitude`!
(Likewise, `leastNormalMagnitude` should be `leastNormalPositive` or
`minPositive`, and `greatestFiniteMagnitude` should be
`greatestFinite` or `maxFinite`)

Inconsistencies with Integer protocols (at least, as they are currently):
* properties named "least..." or "greatest..." are inconsistent with
conceptually similar properties such as `Int.min` and `Int.max`

Use of one term-of-art (`ulp`), as Swift naming guidelines allow and
even encourage, but failure to use more widely understood terms of
art:
* `squareRoot()` should be `sqrt()`
* something really ought to be done about
`truncatingRemainder(dividingBy:)`--the fact that the comments tell
the reader that `truncatingRemainder(dividingBy:)` is equivalent to C
`fmod` suggests to me that `fmod` may be a widely understood
term-of-art

I argue strongly that Swift's naming guidelines about terms-of-art
should be understood to encourage terms used widely in other languages
for basic mathematical functions instead of written-out English
equivalents--e.g. `asinh` instead of`inverseHyperbolicSine`. Looking
to other C-style languages, all seem to accept these shorter terms
as-is without writing them out.


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

Yes. Several pain points exist with current FloatingPoint protocols
that are addressed in this proposal.


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

Partially. In addressing pain points, yes. Some of the proposed method
names could stand improvement for accuracy and for consistency with
the rest of the language, as outlined above.


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

I believe this proposal brings the FloatingPoint protocol up to a
similar level of comprehensiveness as the approximate equivalents in
C-family languages such as C# and Java; however, I think some further
clean-up of the proposed names should be considered.


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

Followed the original discussion of draft proposal carefully; have
used floating point protocols extensively in (current) Swift and in
other languages.