Oh dear. This seems to have been the result of a bad conditional left over when fixing SR-832.

To expand: The rules for matching parallel @autoclosure function types are

• If doing a conversion, strip off the Void input from the second type and recur matching the result against the first type.

• If doing equality, try parallel matches. Both types must have @autoclosure to do so.

The condition in SR-832 instead checks for a mismatch and uses that as evidence it is doing a conversion which, being the identity, succeeds trivially. I'm not sure we can cut this off without severely breaking source (naive fix I have for this indicates that XCTest and Foundation are relying on this).

Yet it's an abuse of a bug, similar like some people abuse

guard let `self` = self else { ... }

in closures with `weak` self.

I see two options (there is third one, but I won't be happy with it in a long term):

1. Fix this issue (provide migration for this `add () at the ende of the forwarded autoclosure`)

2. Align autoclosure with normal closures to accept normal explicit closures with the same signature (however this might have breaking changes in generic area - if I'm wrong here, then this change is more than welcome)

func foo() -> Int { return 42 }
func bar(_ c: @autoclosure () -> Int) { ... }
bar(foo) 

This would allow us to specify autoclosures with default reference to another function/closure:

func foo() -> Int { return 42 }
func bar(_ c: @autoclosure () -> Int = foo) { ... }
bar() 

3. Live with this asymmetric bug.

I think it does need to go to swift-evolution, since it will break existing code. A core team member could rule that it doesn't need a full review, but it should at least come up there.

@swift-ci create

@autoclosure forwarding has been banned starting from `swift-version 5`.