@xedin, seems like a case where SE-0110 behaves worse in Swift 4 mode?

Looks like like a problem with ranking in the swift-version 4 mode because in compatibility mode we still find both of the solutions but somehow `test<T0, T1, TRet>` ranks higher than `test<T0, TRet>`. I'll try to take a closer look at this soon.

Comment by Petro Korienev (JIRA)

Observing similar issue, argument labels make the difference, this can be considered as temporary workaround: https://gist.github.com/soxjke/6c2dff8a8c255ff386f3c325d09300cf

Comment by Sebastian Shanus (JIRA)

Hi there! Any update on this issue?

This is currently blocking our DI framework from upgrading to swift4 because we generate factory functions like:

```

public func to<P_1>(factory: @escaping (P_1) > Input) > BindingReceipt<Input> { ... }

public func to<P_1,P_2>(factory: @escaping (P_1,P_2) > Input) > BindingReceipt<Input> { ... }

```

etc.

sebastianv1 (JIRA User) Unfortunately you'd have to use a workaround for now, by adding labels as suggested or changing function names, ideally we'd have the second overload to match unambiguously but we need to do more refactoring of function type representation to get there.

Comment by Jeremy Lew (JIRA)

I ran into the same problem, and stumbled across a workaround that is (for my purposes) nicer than disambiguating via naming. Take the original repro code above, and alter it as follows:

func test<T0, TRet>( fn: (T0) -> TRet) -> Void
...to...
func test<T0, TRet>( fn: ((T0)) -> TRet) -> Void
(note the extra pair of parens around the T0 callback parameter, which explicitly makes it into a tuple-of-1)

After this change, test(fn2) compiles and calls the test<T0,T1,TRet>

It seems like the compiler is able to treat a function with N arguments as a function with one N-way-tuple argument. Hence, both the (T0) -> TRet and (T0,T1) -> TRet overloads are candidates for fn2, and the call is ambiguous. Adding 2nd pair of parens ((T0)) -> TRet limits that overload to an argument with a single parameter or 1-way tuple.

sebastianv1 (JIRA User): My problem was with a DI framework as well, perhaps this will help your case.