> On Feb 22, 2017, at 8:01 AM, Ben Cohen via swift-evolution
> <[email protected]> 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.
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
[email protected]
https://lists.swift.org/mailman/listinfo/swift-evolution
