@swift-ci create

I think this was caused by [#29845 [ConstraintSystem] Accept trailing closure if multiple defaulted parameters after last function parameter|#29845], which landed in this range and would have made the first overload a candidate when it previously wasn't.

@omochi @xedin Do we have a good way to fix this other than reverting? For instance, giving the previously-preferred overload a better score?

Yeah, I think this should be possible to fix by ranking first overload lower in case like "expect { 1 }" because having @autoclosure means that T is going to be `(() -> Int)?` which is not what anybody would expect...

Certainly it is a regression by my code. I'm sorry.

More generally, I've noticed that my patches have produced the following regressions.

func f(aa: () -> Int, bb: Int = 0, cc: Int = 0) {
  print(1)
}

func f(bb: Int = 0, cc: Int = 0, aa: () -> Int) {
  print(2)
}

f { 0 }

// Xcode11.3 => 2
// master => ambiguous use of 'f'

If this is permissible, then in this case, as @xedin says, the inference for @autoclosure should be patched.

When Trailing closure is followed by a defaulted argument instead of an actual last argument, how about increasing the score proportionally to its number?

Unfortunately to maintain source compatibility we'd have to revert your changes @omochi. Once that's done I'd add these test-case as a separate PR.

OK🙂

Increasing score like that would be arbitrary, solver would already rank based on number of defaulted arguments, it shouldn't matter where they are positionally.

Revert is located at - #30656

saeta (JIRA User) Changes have been reverted and I have merged new test-cases via #30680 Please verify using next available nightly snapshot of master branch and close.