[Pitch #2] Forward scan matching for trailing closures

[Jumhyn (Frederick Kellison-Linn)]

I'm quite happy with this iteration of the pitch, and am glad we're approaching this from a direction that doesn't end up polluting function signatures with tons of attributes.

@anandabits

Why do we need to limit the heuristic to calls with a single unlabeled trailing closure? Would it be viable to say if the matched parameter has a default and the call site does not compile when that call parameter is chosen you apply the default and examine the next parameter?

When you talk about the "matched parameter" here, are you referring to the matched parameter of the unlabeled/first trailing closure only?

If we decide that the heuristic should live on past Swift 5, I think the rule should definitely take the form you suggest, since we'd otherwise end up in the same situation where adding additional trailing closures can change the parameter matched to a closure:

func trailingClosures(arg1: () -> Void = {}, arg2: () -> Void, arg3: () -> Void = {}) {}
trailingClosures { print("Hello!") } // By the heuristic, this matches arg2
trailingClosures { print("Hello,") } arg3: { print("world!") } // Now, an error!

This inconsistency seems not-ideal (but perhaps acceptable) if it's a temporary mitigation of source breakage. However, if we do want the heuristic to stick around (and I think you've given a compelling argument for why we might, @anandabits) then we should apply it to multiple trailing closures as well.

@anandabits

I don’t understand why if it is acceptable for Swift 5.x we would drop it in Swift 6 and start requiring libraries to use an overload-based design.

I think the position of the pitch makes sense if we assume that the heuristic is unacceptable as a long-term citizen due to the complexity it adds to the resulting forward-scan rule. For Swift 5, we have to maintain source compatibility as much as possible, so a more-complex-than-ideal rule is viewed as the lesser of two evils when compared to a more extensive source break. When we move to Swift 6, though, we are no longer constrained by the same compatibility requirements so we are free to have the forward scan procedure adopt the 'ideal' rule.