For me trailing closures were always among the best looking and most compelling syntactic features Swift had to offer. They fit the language because they are IMHO straightforward and easy to understand.
Therefore I think that it is a no-brainer, to extend this syntactic sugar, where it's usability is limited. I agree with the arguments presented in the proposal that this is e.g. the case, when there are multiple (possibly defaulted) closure parameters at the end of a function.
I think that the proposed syntax builds really well on top of our current trailing closures and that the simplicity is perfectly maintained, at least in the presented examples.
As many others also mentioned in this thread, I can think of some use cases though, where the API design would really benefit from the option to explicitly state the argument name of the first trailing closure too. This would be especially useful for functions, which take multiple equally important closures.
Binding(get:set:) mentioned by @Lantua is probably the most prominent member of this group of functions.
APIs designers should even get the possibility to obligate the explicit first trailing closure argument name IMHO, because I believe as many others, that the caller of the API should not necessarily have to decide for or against it by himself.
Something like an opt-in function annotation like @michelf suggested here should be considered (obviously the best approach would be to require the argument name, if the label wasn't underscored in the function declaration, unfortunately that would be source breaking).
I would definitely be +1 for this proposal, if it became possible, to label all trailing closures and to require such use in an API. It would also make the Renaming Trailing-closure Functions in the Standard Library pitch somewhat obsolete, which I would rather appreciate.
In my eyes yes, especially if labelling all trailing closures became a thing.
Definitely. IMHO it extends the current trailing closure syntax very naturally and also follows the current direction of Swift, by allowing e.g. better DSL-APIs.
I read the proposal and the whole second review thread.