> * What is your evaluation of the proposal? Looks good to me.
`RoundingRule.toNearestOrEven` is a fine name, but I would like the documentation to mention the term "bankers' rounding", a traditional term which Foundation uses for the same algorithm. (Actually, it might be a good idea to talk to the Foundation guys and see if you can get them to implement `toNearestOrEven` and then replace `NSDecimalNumber.RoundingMode` with `Swift.RoundingRule` in their Swift APIs. This would undoubtedly require some coordination of raw values and so on.) On this question: >> …although we may consider suppressing the imported, global-level C >> functions, or perhaps automatically migrating them to the new >> instance-method calls. I would suggest that we suppress the C functions and replace them with generic versions which take a FloatingPoint parameter and call through to `rounded(_:)`. If people want to use the terms of art here, there's no strong reason to fight them on it. > * Is the problem being addressed significant enough to warrant a change > to Swift? Yes; we want to cover all of IEEE 754, and this is a piece of that. > * Does this proposal fit well with the feel and direction of Swift? Yes. This is a very elegant way to handle rounding. > * If you have used other languages or libraries with a similar feature, > how do you feel that this proposal compares to those? I can't believe how many languages have slavishly copied C without trying to improve on it. > * How much effort did you put into your review? A glance, a quick > reading, or an in-depth study? Quick reading, a little bit of research on Decimal's rounding support. -- Brent Royal-Gordon Architechies _______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
