# [swift-evolution] [Review] SE-0113: Add integral rounding functions to FloatingPoint

Stephen Canon scanon at apple.com
Fri Jul 1 06:59:06 CDT 2016

```> On Jul 1, 2016, at 7:44 AM, Joseph Lord via swift-evolution <swift-evolution at swift.org> wrote:
>
>
>> The review of "SE-0113: Add integral rounding functions to FloatingPoint" begins now and runs through July 5. The proposal is available here:
>>
>>   https://github.com/apple/swift-evolution/blob/master/proposals/0113-rounding-functions-on-floatingpoint.md
>>
>>   * What is your evaluation of the proposal?
>
> It is an improvement but would it be even better if the return type was Int (or possibly type inferred to Int16 etc.). If a float is really desired it can be initialised from the Int (or it could even infer float result is required).

This is a common thought, but it's precisely backwards from a numerics and pragmatics perspective.  The result is always representable as `Self`, and generally not representable in any fixed-width integer type.  If you have the version that produces `Self`, getting an integer falls out trivially:

let y = Int(x.rounded(.up))				[1]

But if you only have the version that produces an integer result, you’re stuck with a much more complex workaround when you actually need the result as `Self` (which is more common than you think).  In the best case scenario, where `Int` is bigger than the significand of `Self`, it’s not *too* bad, but still requires at least a conditional and two conversions.  In the bad scenario, a floating-point type whose significand doesn’t fit in `Int`, you end up needing to write all the rounding logic yourself.

The idea of also having a set of Integer inits that round has been mentioned once or twice in the past:

let y = Int(roundedUp: x)

I’m not sure if that’s really any cleaner than [1], but it could certainly be considered as another proposal.

– Steve
```