[Pitch #1] Forward scan matching for trailing closures (source breaking)

[Douglas_Gregor]

@anandabits

I’m very uncomfortable with maintain both forward and backward scanning indefinitely. I think having both rules would be confusing for many programmers. I would not be surprised to find myself confused by this design from time to time.

Whatever we change, we will be living with both the "Swift 5 rule" and the "Swift 6 rule" for a very long time. In your proposal, it's "the unlabeled trailing closure can match a labeled argument" vs "it cannot match a labeled argument." I assert that it's important to make very limited changes that affect as little code as possible, so most Swift 5 code acts identically to Swift 6 code.

@anandabits

I don’t think we should disable trailing closures on an argument by argument basis.

I agree; I'm removing this from my pitch because it's control we don't need, and argued that the sheet(isPresented:onDismiss:content:) example is not in line with the API design guidelines.

@anandabits

func sheet(
  isPresented: Binding<Bool>,
  onDismiss: (() -> Void)? = nil, 
  @elidedWhenFirstTrailingClousre content: @escaping () -> Content
) -> some View

With this attribute in hand, we can now express the desired API while also allowing multiple trailing closures to work the way most people seem to want them to work.

After looking at this, I realized that the forward scan already provides a way to strongly discourage you from specifying the last parameter, by leaving it unlabeled:

func sheet(
  isPresented: Binding<Bool>,
  onDismiss: (() -> Void)? = nil, 
  _ content: @escaping () -> Content
) -> some View

You could write:

sheet(isPresented: $flag, onDismiss: { doSomething() } ) 
   _: {
       // content
   }

but, well, that _: is a strong indicator that you're working against the API author. And it's a simpler solution than either of the attributes you or I proposed for this specific issue. And as I note in my updated pitch, this API should probably be:

func sheet(
  isPresented: Binding<Bool>,
  content: @escaping () -> Content
  onDismiss: (() -> Void)? = nil, 
) -> some View

such that defaulted parameters go toward the end, something that is supported with forward scanning.

@anandabits

I continue to think the best solution is to treat trailing closure labels like any other argument labels.

This implies a forward scan, because that's how argument labels are matched. So I don't think we're actually debating the forward scan per se, but whether trailing closures must have argument labels matching that of the parameter call site in Swift 6 (your proposal) or we update the current scheme of ignoring the argument label by skipping over non-closure arguments (my proposal).

@anandabits

Is having a migrator automatically apply an attribute to labeled, single closure argument function declarations really so problematic as to motivate living with a suboptimal design for trailing closures indefinitely?

It's less about the migrator, and more about whether most Swift 5 code and most Swift 6 code work roughly the same. With my proposal, the changes affect APIs with multiple closure parameters and defaults in non-standard places (i.e., before the end). With your proposal, even a simple declaration lifted from the standard library:

func sorted(by predicate: (Element, Element) -> Bool) -> [Element] { ... }

with either need some kind of historical-accident attribute (@elidedWhenFirstTrailingClosure) or will have a different call signature in Swift 5 (sorted { $0 > $1 }) and Swift 6 (sorted by: { $0 > $1 }). That invalidates a lot of code that exists today, including code in books and tutorials where one cannot automatically apply a migrator.

The "Source Stability" section of the Principles for Trailing Closure Evolution Proposals thread contains this example:

subscript currently deviates from regular function declaration, in that parameter names are not argument labels. Instead you must use explicit argument labels. This is confusing, and might be better made consistent, but would cause extensive source breakage. While this could be language versioned, it would cause considerable source churn and block adoption of other Swift features in the same version. The consistency benefits are therefore clearly outweighed by the cost.

I consider your proposed design to be in a situation nearly identical to what the Core Team has described above: Yes, having a single set of matching rules would be more consistent that having the unlabeled trailing closure argument behave differently. Yes, the migration could be automated with the attribute. But the scope of the change you're proposing is larger (both conceptually and in the volume of changed code) than the subscript one above, and the Core Team preemptively rejected that by using it as an example.

(Full disclosure: my two hats are stacked lopsidedly on my head right now. I brought the subscript example up to the Core Team because I felt like it was good for establishing precedent (either way!) about how much source code churn could be considered in a new language version. Now I'm wielding that precedent to support my own proposal against an alternative.)

Doug