cc @xedin, @rudkx

@swift-ci create

@iby, what is the output of running swiftc --version with the compiler that worked as expected vs. the one that did not?

One that ships with latest Xcode 9.2:

Apple Swift version 4.0.3 (swiftlang-900.0.74.1 clang-900.0.39.2)
Target: x86_64-apple-macosx10.9

@iby, I tried your example with Xcode 9.2 (and earlier Xcodes) and see the same error about the call to g1 being ambiguous.

I agree offhand this seems like something we should be able to disambiguate, but I don't think this is a regression from Xcode 9.2.

Are you sure this code is representative of what you had compiled successfully with Xcode 9.2?

@rudkx yes, I missed elephant in the room. Frankly, this all comes down to Equatable conformance:

The difference in behavior here is a result of {Optional} becoming {Equatable}. Previously there was a single overload that worked for type checking:

let x2: G<String?> = g1(key: "foo")

but now both overloads work, and neither is considered better.

The only workaround that comes to mind for disambiguating here is somewhat ugly. You could add a dummy protocol requirement and extensions for the (non-Optional) types that you'd like to use this with, e.g.:

protocol P {}
extension String : P {}

func g1<T: Equatable & P>(key: String) -> G<T> { return G() }
func g1<T: Equatable & P>(key: String) -> G<T?> { return G() }

let x2: G<String?> = g1(key: "foo")

Thanks for looking into and suggestions. I didn't realise the issue was so broad and not just a regression. The fact that it was working all that time is just me being lucky. I'll refactor the code, but I think it's a good idea to be able to disambiguate these things.

Yes I agree it would be good if we could find a principled way to disambiguate here.

Thanks for reporting this.