I have followed the discussion around this on the Swift forums, and I'm actually of the opinion that the debate around this topic amounts to little more than bi

I have followed the discussion around this on the Swift forums, and I'm actually of the opinion that the debate around this topic amounts to little more than bikeshedding and the proposed syntax for multiple trailing closures is fine. I'm a bit perplexed by the author's position that Swift should just be small-talk as though this is obviously better. As far as the idea of getting rid of parens entirely as the author suggests, I'm not a big fan of this approach. In languages like ruby where parens are not used, I tend to find this makes things a lot less readable. That might be a matter of opinion, but at the very least I think it can be said that Swift's approach to arguments, where only closures can be moved out of the parentheses of a function call is a perfectly consistent and defensible approach. For instance I don't think that this: foo(someArg: 42) { // do something } Is less clear than this: foo doSomething: { do something } someArg: 42 In fact I think it's probably the opposite, and the only reason I can imagine to prefer the second example would be out of some appeal to purity/simplicity of the function call syntax over any level of pragmatism. As far as the whole debate over the inconsistency of the first argument label being removed while the following argument labels are required in multiple-trailing-closure syntax, I just don't think it's that big a deal. I also understand the consistency argument, that it should be handled the same for all arguments (i.e. the author of the function signature should explicitly decide if the label is required or not), and it probably should work that way, but I also understand why it hasn't been proposed that way for the first iteration. It would break a lot of code given how prevalent trailing closures are in Swift. However there are already proposals in the pipeline to introduce an argument label in the first trailing closure (provided the function author hasn't named it `_`). I suspect in the long term this will eventually make it into the language, and automatic migration tools will make it possible to resolve issues with existing code without much fuss. So in short I think multiple trailing closures are a good and natural addition to the language which provide real value, and the proposed syntax is absolutely fine.