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

[Jumhyn (Frederick Kellison-Linn)]

@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.

I'm in strong agreement with @anandabits here. This proposal only seems to complicate the rules around trailing closures, and would require programmers to memorize whether individual APIs provide "forward" or "backward" matching rules in order to effectively use them.

@anandabits

I continue to think the best solution is to treat trailing closure labels like any other argument labels. As with this pitch, an opt-in attribute would be used during a migration period.

I agree—so many of the issues around multiple trailing closure syntax (and trailing closure syntax in general) seem to arise from the fact that it is a weird corner of the language where the existing rules for parameter labels are thrown out the window. If we're comfortable with a source change in a new language version, I believe that this solution most effectively satisfies the Control of the Call Site and Language Consistency and Future Directions principles that Ben outlined in Principles for Trailing Closure Evolution Proposals.

@anandabits

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

Rather than introduce an additional attribute to support further special-casing of the rules around trailing closure labels, I would instead expect the API to be changed to read as:

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

The call site examples you've written would then read as:

sheet(isPresented: $flag)
    onDismiss: { 
         // several lines of code
    }
    _: {
         // the content
    }

and (same as today):

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

IMO, this leaves the language in the best place consistency-wise, and results in very predictable rules for programmers to follow at the call site.