SE-0279: Multiple Trailing Closures

Evolution Proposal Reviews
382

Having some sore of indicator (like .$ or .# or :) would be better than having an unknown number of trailing closures floating around after function calls.

That's one thing the original proposal has going for it, it scopes the argument labels so it is unambiguous who they belong to (and that they are actually trailing closures).

When we look at the single trailing closure syntax, we can clearly identify it as a trailing closure because it does not have enough information to stand as its own statement. Plus, it is literally right next to the function call.

foo(bar) { baz in
  baz.add(3)
}

But if we make the trailing closures labeled (which is necessary for multiple closures) and connect them only by proximity to the previous closure, it becomes difficult to differentiate this

foo(bar) process: { baz in
  baz.add(3)
} 
package: { baz in
  baz.zip()
}
translate: { baz in    // Trailing closure named "translate"
  baz.localize()
}

from this

foo(bar) process: { baz in
  baz.add(3)
} 
package: { baz in
  baz.zip()
}
translate { baz in   // Function named "translate" with single trailing closure
  baz.localize()
}

because once we add the label, we are only one character away from it being a syntactically valid function call itself.

Yes, indentation would help differentiate in this example, but it should not required.

2 Likes