Do you have any feedback on that article's thesis that the closure syntax could have been handled better?
Every programming language changes as it evolves and matures and people understand how to use it best or its domain changes significantly. Unfortunately, this always means accumulating these syntactic and semantical warts. Personally, I think Swift manages to keep a good balance, and it's a very powerful language, with lots of users and compatibility requirements, so it's much harder for them than for many others.
Alternative is constant redesign of syntax and behavior that just keeps making users unhappy with every release, breaking their code, libraries and obsoleting the docs.
If, to mitigate that, you try to make big changes to the language in big releases, once in a long while, you can easily get into the Python 3, Scala 3, Perl 6 fiasco and that can simply kill the language adoption.
It's a hard problem.
As regards Perl 6, a recent development was to rename it to Raku, which (in hindsight) seems like a perfectly sensible decision. The overloading of the name Perl for a language that proved to be something different from Perl 5 caused trouble both ways. Perl 5 was widely considered to be a version that was to be eventually be replaced, whereas Perl 6 was considered a language that was a close and direct iteration of Perl 5. So we basically got the worst of both worlds. Perl 5 is very much in use today, still being actively maintained and is getting new features regularly, while Raku/Perl 6 is a beautiful new different language with interesting ideas being worked on by many brilliant folks, and the notion of trying to be in any way compatible with Perl 5 seems utterly irrelevant today.
I know they aren't big because Perl has had to deal with many of those same type of problems, only it didn't have to break old code to do it.
Perl 6 is more of a research project that took Perl 5 as a leap-off point. As it is is such a large departure from every language, it deserves it's own name. So it is now known as Raku.
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
}
foo doSomething: {
do something
}
someArg: 42
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.