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

[Chris Lattner]

> On Jul 6, 2016, at 9:16 PM, Pyry Jahkola <pyry.jahkola at iki.fi> wrote:
> 
> I think one more thing needs clarification. Shouldn't the "defaulted" `rounded()` and `round()` be defined as protocol extension methods *without* the possibility to override the default rounding mode in a conforming type? Like so:
> 
>    public protocol FloatingPoint {
>      ...
>      func rounded(_ rule: RoundingRule) -> Self
>      mutating func round(_ rule: RoundingRule)
>    }
> 
>    public extension FloatingPoint {
>      public func rounded() -> Self {
>        return rounded(.toNearestOrAwayFromZero)
>      }
>      public mutating func round() {
>        round(.toNearestOrAwayFromZero)
>      }
>    }
> 
> I would find it quite surprising if some type conforming to FloatingPoint rounded differently by default than the others.

Yes good point.  That is my mistake summarizing the discussion of the core team today.  This is indeed how it should be structured.

-Chris


> 
> — Pyry
> 
>> Chris Lattner wrote:
>> 
>> Since protocol requirements cannot currently have default arguments, the desired behavior should be achieved with two overloads of each operation:
>> 
>> protocol FloatingPoint {
>> ...
>> /// Returns a rounded representation of `self`, according to the specified rounding rule.
>> func rounded() -> Self
>> func rounded(_ rule: RoundingRule) -> Self
>> 
>> /// Mutating form of `rounded`.
>> mutating func round()
>> mutating func round(_ rule: RoundingRule)
>> }
>> 
>> Where the no argument cases can be implemented with a protocol extension that forwards to the single-argument versions.