@swift-ci create

I'm not sure the problem here has something to do with forward scanning closures, to me this is on overload selection where for some reason the solver is selecting overload 2 so to me is just a type inference issue. Given that introducing a new overload apparently unrelated causes the problem might the case where when there's only two overload solver can apply some favoring overload 1 where if we introducing a new one exposes the problem. We stumble on something similar before in #53977, where ambiguity was introduced after adding a third overload. In order to solve this we have to find out why solver is choosing overload 2.

This is indeed an issue, but as a workaround just to make it compile, you could explicitly add a contextual type in order to "tell" the compiler that you actually want overload 1 like:

func test(input: Box<Void>) -> Box<String> {
    let output: Box<String> = input.map { "foo" }
    return output
}

// or 
func test(input: Box<Void>) -> Box<String> {
    let output = input.map { "foo" } as Box<String>
    return output
}

// or 
func test(input: Box<Void>) -> Box<String> {
    return input.map { "foo" } 
}

In all those cases specifying the contextual type, the solver introduces a new constraint that makes the solver reject the overload 2 as no viable in this context, so only overload 1 is applicable.

cc @xedin

Comment by Ryder Mackay (JIRA)

Right, sorry I should've mentioned that too—we did work around the issue by adding explicit type annotations to the local variable just like your first example there. Thanks for looking into this!

I think this is a new behavior with seems to be associated with forward-scan for trailing closures which also landed very late in Xcode 12 development cycle. /cc @DougGregor

@DougGregor ping.

Revision update: Swift 5.9-dev (c1d5118)