> On Jul 6, 2016, at 9:16 PM, Pyry Jahkola <[email protected]> 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.
_______________________________________________
swift-evolution mailing list
[email protected]
https://lists.swift.org/mailman/listinfo/swift-evolution
