A question, perhaps Stephen's to answer: apparently IEEE754 defaults to what we're calling `toNearestOrEven`? Should Swift be using that as the default as well?
On Wed, Jun 29, 2016 at 7:41 PM, Karl Wagner <[email protected]> wrote: > 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]> wrote: > >> >> On Jun 29, 2016, at 2:06 PM, Xiaodi Wu <[email protected]> wrote: >> >> On Wed, Jun 29, 2016 at 12:12 PM, Stephen Canon via swift-evolution < >> [email protected]> wrote: >> >>> >>> On Jun 29, 2016, at 1:10 PM, Matthew Johnson <[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
