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

Evolution Announcements
1

Proposal Link: swift-evolution/0113-rounding-functions-on-floatingpoint.md at master · apple/swift-evolution · GitHub

The review of "SE-0113: Add integral rounding functions to FloatingPoint " ran from June 30 ... July 5, 2016. The proposal has been *accepted*:

The community and core team agree that this proposal helps to “round out" the other Swift 3 numerics work. One minor revision is necessary to make the proposal implementable in Swift 3. 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.

Thank you to Karl Wagner for driving this discussion forward! I filed SR-2010 to track implementation work on this.

-Chris Lattner
Review Manager

2

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.

— 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.

3

Small correction: actually the no-argument cases don't need to be declared as requirements in the protocol.

···

Sent from my moss-covered three-handled family gradunza

On Jul 6, 2016, at 8:46 PM, Chris Lattner <clattner@apple.com> wrote:

Proposal Link: https://github.com/apple/swift-evolution/blob/master/proposals/0113-rounding-functions-on-floatingpoint.md

The review of "SE-0113: Add integral rounding functions to FloatingPoint " ran from June 30 ... July 5, 2016. The proposal has been *accepted*:

The community and core team agree that this proposal helps to “round out" the other Swift 3 numerics work. One minor revision is necessary to make the proposal implementable in Swift 3. 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.

Thank you to Karl Wagner for driving this discussion forward! I filed SR-2010 to track implementation work on this.

-Chris Lattner
Review Manager

_______________________________________________
swift-evolution-announce mailing list
swift-evolution-announce@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution-announce

4

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

···

On Jul 6, 2016, at 9:16 PM, Pyry Jahkola <pyry.jahkola@iki.fi> wrote:

— 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.