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