As I stated before during the pitch phase, it's clear that a forward scan rule for trailing closures is almost inevitable. I support the envisioned final design for matching closures to parameters.
This particular revision of the proposal is greatly improved from the first draft; I think it is a very positive development that we are not exposing so many knobs and dials to end users for what essentially are language rules.
The heuristic is very clever.
That said, my overall evaluation of the proposal is that it is inconsistent with the core team's stated principles regarding the evolution of trailing closures. A different roadmap for staging in this change that is not source breaking in a minor version would, I think, be compatible with those principles--and I happen to believe that it would be simpler to use and teach.
Yes, for the reasons outlined in the proposal text itself.
In its final design—yes.
In the proposed path to stage in that change—no; in fact, it is in direct conflict with the core team's sole sine qua non requirement for proposals in this area:
(Emphasis original.)
Therefore, although the heuristic is very clever and does greatly cut down on the degree of source breakage, its adoption for the next minor version of Swift runs counter to the articulated must.
Instead, I would suggest the following migration story:
- In the next minor version of Swift, implement forward scan and backward scan; where the two "scans" do not match, backward scan "wins" (i.e., all code continues to work as it currently does) but the compiler emits a warning.
- (If we had the option of labeling the first trailing closure, then the warning could then be silenced by explicitly labeling, but we don't have that option at least currently.) For now, the warning can be silenced by not using trailing closure notation. This is not necessary convenient to write, but a fix-it can help automate the task. When the fix-it is applied, the code is made future-proof for a future version of Swift.
- In Swift 6 (or whatever the next major version is called), forward scan "wins" (unless the compiler is used in a Swift 5 compatibility mode).
- When Swift 5 compatibility mode is dropped, so too is backward scan from the codebase.
I don't know of another language where this issue arises.
I have done an in-depth study of the issues and participated at all stages of this proposal and of related proposals.