Since closures can use anonymous arguments, sometimes the compiler has to look inside to resolve ambiguities. However, it will only do this for a closure that consists of a single expression, to avoid trying to infer types across statement boundaries.

@xedin, what do you think about using the number of arguments when it is provided, though? At least in Swift 4 and 5 mode, where it can't accidentally be a tuple unsplat?

The problem here is that non of the overloads on "reduce" actually match for

let reducedToDictionary1 = values.reduce(
    into: [Int:String]()
)
{ accumulation, element in
    accumulation[element.0] = element.1
}

because there is no return (and argument label), which doesn't match "reduce" defined by standard library (it expects Result type returned from the trailing closure), and there is no 3rd argument which would match new overload. So it looks like the first call to reduce is legitimately ambiguous...

I guess we could have a diagnostic which should stay that expected result is not produced or something like that to improve situation here...

No actually we can't do that, the best would be to tell that there is an argument missing

I'm confused by your comment that "none of the overloads on "reduce" actually match for..."

When uncommented, "reducedToDictionary2" matches and compiles just fine, utilizing the standard library's

reduce(into:_:)

method by way of adding a second line to the trailing closure. It's an example of overload resolution working properly - with the caveat that adding the second line to the trailing closure is weird and shouldn't be necessary.

I'm also confused by your comment: "which doesn't match "reduce" defined by standard library (it expects Result type returned from the trailing closure)". There are two "reduce" methods in the standard library. The trailing closure argument for the

reduce(_:_:)

variant returns Result. That variant of "reduce" shouldn't come into play here.

In all the examples provided, the

reduce(into:_:)

variant is being called. The trailing closure argument of the latter variant returns ().

Sorry @djehrlich I missed reduce(into:_) for some reason... It seems like "reducedToDictionary1" is supposed to use the overload from standard library. I will investigate further.

@djehrlich Can you actually try using the latest trunk snapshot (https://swift.org/download/#releases)? It looks like this problem has been solved on master branch, i think it's related to subtyping with inout parameters (something I've recently fixed).

Pavel,

I pulled down "Trunk Development (master)" from https://swift.org/download/#releases and added it as a toolchain to Xcode. You were correct: the problem is solved on this branch. For posterity, I'm attaching screen shots: ReduceIntoAmbiguity1.png & ReduceIntoAmbiguity2.png.

Thanks!

--David

Thanks, @djehrlich!