[swift-evolution] [Proposal] Add floor() and ceiling() functions to FloatingPoint

[Karl Wagner]

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 <xiaodi.wu at gmail.com> wrote:
> 
> On Wed, Jun 29, 2016 at 1:07 PM, Stephen Canon <scanon at apple.com <mailto:scanon at apple.com>> wrote:
> 
>> On Jun 29, 2016, at 2:06 PM, Xiaodi Wu <xiaodi.wu at gmail.com <mailto:xiaodi.wu at gmail.com>> wrote:
>> 
>> On Wed, Jun 29, 2016 at 12:12 PM, Stephen Canon via swift-evolution <swift-evolution at swift.org <mailto:swift-evolution at swift.org>> wrote:
>> 
>>> On Jun 29, 2016, at 1:10 PM, Matthew Johnson <matthew at anandabits.com <mailto:matthew at anandabits.com>> 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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160630/c1c54156/attachment.html>