[swift-evolution] [Re-Review] SE-0104: Protocol-oriented integers

Max Moiseev moiseev at apple.com
Wed Feb 22 12:55:14 CST 2017


> On Feb 22, 2017, at 8:47 AM, David Sweeris via swift-evolution <swift-evolution at swift.org> wrote:
> 
> 
>> On Feb 22, 2017, at 8:01 AM, Ben Cohen via swift-evolution <swift-evolution at swift.org <mailto:swift-evolution at swift.org>> wrote:
>> 
>> There is another option to avoid the extra types, which is to stop trying to force the disambiguation through argument labels, accept an ambiguous call and have the context disambiguate:
>> 
>> // compilation error: ambiguous
>> let x = i.multiplied(by: j)
>> // unambiguously overflow-checked
>> let (y,overflow) = i.multiplied(by: j)
>> // unambiguously full-width
>> let z: DoubleWidth = i.multiplied(by: j)
>> 
>> Ambiguity is bad when you want to distinguish between the “usual one” versus other more specialized versions. So if you really had a regular trapping `adding`, but then also wanted to accommodate the overflow-reporting version when a user explicitly requests it, then the argument label is a clear win. This is a slightly bogus example though, because we explicitly don’t have things like `adding`, we have a `static +` instead. Where the disambiguation is needed is instead between two less common variants as described above.
> 
> It’d need a new language feature to support it, but what having “default” resolutions for overloaded functions?
>     default func multiplied(by other: Self) -> Self // `default` means try resolving ambiguities with this version first. The overloaded versions are only considered if the type-checker can’t make this version work.

This feature is not strictly required in this case, as we moved away from using `multiplied` of type (Self, Self) -> Self to using proper `static func +`. So the ambiguity will *not* happen in the most common case when you want to multiply two numbers of some type and get the result of the same type. Ambiguity will only become a problem in what I believe to be a very less frequent case, when you want to do something very special, like, catch the overflow explicitly or get the full result in a form of DoubleWidth<T>.

>     func multiplied(by other: Self) -> (partialValue: Self, overflow: ArithmeticOverflow)
>     func multiplied(by other: Self) -> DoubleWidth<Self>
> 
> // signature matches default implementation, use that 
> let x = i.multiplied(by: j)
> // default version doesn’t return a tuple, so try the overloads… matches the overflow-checked function
> let (y,overflow) = i.multiplied(by: j)
> // default version doesn’t return a DoubleWidth, so try the overloads… matches the double-width function
> let z: DoubleWidth = i.multiplied(by: j)
> 
> - Dave Sweeris
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution

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


More information about the swift-evolution mailing list