OK I’ve incorporated those small things and submitted it for review. We’ve had an initial discussion, incorporated all the feedback, so I think it’s met the bar for a PR 👍
https://github.com/apple/swift-evolution/pull/394 Karl > On 29 Jun 2016, at 20:20, Xiaodi Wu <[email protected]> wrote: > > On Wed, Jun 29, 2016 at 1:07 PM, Stephen Canon <[email protected] > <mailto:[email protected]>> wrote: > >> On Jun 29, 2016, at 2:06 PM, Xiaodi Wu <[email protected] >> <mailto:[email protected]>> wrote: >> >> On Wed, Jun 29, 2016 at 12:12 PM, Stephen Canon via swift-evolution >> <[email protected] <mailto:[email protected]>> wrote: >> >>> On Jun 29, 2016, at 1:10 PM, Matthew Johnson <[email protected] >>> <mailto:[email protected]>> wrote: >>> >>> My criticism of the 'toNearestOrGreatest' still stands though. I think >>> this name is misleading given the stated semantics. The name indicates >>> "greater value" not "greater magnitude" which are opposites in the case of >>> negative numbers. >> >> Yup, I agree. I think I originally suggested `toNearestTiesAway`. I’m not >> tied to that name specifically, but we should be clear that ties go away >> from zero, not up. >> >> Agreed; `toNearestOrAwayFromZero` is the most accurate and consistent >> description. > > Worth noting that since this is the defaulted behavior, we can get away with > a wordy description. > > This is really picking nits, but the most common behavior would be best as > the first enum case, no? Maybe go roughly from most-value-preserving to > least-value-preserving, like so: > > `enum RoundingRule { case toNearestOrAwayFromZero, toNearestOrEven, up, down, > towardZero }` > > > > – Steve
_______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
