Having just read the summary (> 40 comments) of this very emotionally loaded thread and without having participated in the reviewing processes before, I don't really understand the backlash of the community here. Right from the beginning, the comments seemed very mean against the core team with subtle attacks like "I don't want to speculate what other things influenced that decision" (which implies the statement "obviously, other things have influenced the decision"). Such accusations don't help anyone and set the tone of the thread – we've all seen what happened thereafter. Let's all be as constructive and positive as possible, we're all in hard times with the current world health situation already, let's not make it worse than that.
I can completely understand the rationale of the core team given the many APIs we have already defined in the recent years which build on the existing trailing closure behavior and I like the proposal exactly the way it is. What I like most about it is that it's focused on just one aspect which is adding more trailing closures with a new syntax as an additive change without breaking code.
This allows for subsequent proposals which can extend that feature, which the proposal even explicitly mentions in its closing section with exactly the example that seems to have driven most of the backlash:
The proposed syntax could be extended to allow users to optionally label the first trailing closure
If we want to have features A, B and C in the Swift language, why is it such a bad thing if A was accepted without B and C included to postpone discussions about the details of B and C to later so things are not getting mixed up in discussions? I think that's a very reasonable decision.
Having that said, I highly dislike the syntax given as an example for the optional first argument label, having a whitespace as a separator between the function name and parameter label as in ipAddressPublisher.sink receiveCompletion: { doesn't feel like Swift to me at all. So IMHO it's a good idea to not accept that part yet and move that discussion into a separate thread to keep things focused, as was already done by @xwu as mentioned in the previous comment.
I just want to thank the core team and hope they will keep up their good work!
That's the part you're missing. The reception in the review threads was, in my opinion, very mixed if not poor. Both in terms of expanding trailing closure syntax period and in the specific way proposed. The fact that the proposal went through two relatively contentious reviews and then was accepted without modification feels suspiciously like a repeat of last year's property wrapper and function builder proposals, which were required for SwiftUI.
It's a bad thing if you only want A iff B comes along with it. In this case, a subset of people were only a fan of multiple trailing closures if there are still first-parameter labels. Obviously there is a proposal for that up, but the reaction from the core team seems rather lukewarm there.
Fair enough, of course I don't know the full story and that could explain why I don't understand the backlash. I just wanted to give an outsiders view to this thread only and mainly the proposal itself to keep things objective.
But even if the reception of the community wasn't only positive, isn't it exactly the point of having a core team that secrecy about other plans regarding Swift and its ecosystem can be kept private to surprise us all with something that we will all learn to love after WWDC? I mean, if it were that everything would be decided by the community, there would have been a more democratic decision making step at the end in the first place, wouldn't there? But that was never meant to be and I still trust our core team. I'd rather prefer amazing new technology like SwiftUI and Combine that drive the language forward in more ways than we can imagine, than having a perfect democratic decision making which slows down innovation more often than not.
Also, if "a subset of people" want A only if B comes along with it, but the core team (and me included) just plain disagree about that, then of course the core team has still considered the arguments and opinion of the community, but decided against it, so a "lukewarm" reaction to subsequent proposals is very natural. That happens sometimes and I think it's a question of trust to live with that. The only time I would be worried is when their rationale wouldn't make any sense, but I don't see that being the case here. They clearly explained that they simply prioritize non-breaking changes over breaking ones for this syntax sugar improvement for the time being. The main improvement (enabling multiple closures) is still there and it's extensible, so I think it's a good compromise.
To me, this all sounds just like a communication issue and I'm sure the core team members were emotionally affected enough to think about ways to prevent such a situation in the future. So in the end I hope we all leave this tough discussion strengthened. Maybe WWDC will shine a different light on this, maybe not, let's grab a cup of , wait and .
I'm just being nitpicky here, but neither SwiftUI nor Combine is part of Swift. Technically they aren't even expressible in Swift, because function builders are not standardised in Swift yet.
That doesn't mean that SwiftUI and Combine are not driving Swift forward. You just mentioned function builders, which is a good example of how they move Swift forward, even if they aren't implemented or merged yet. They probably will sooner or later in one form or another.
My memory could definitely be hazy due to only lurking and not participating. I was more drawing similarities to the fact that the property wrapper proposal(s) generated a lot of review discussion for a feature that was predestined to land.
It did, and that discussion reshaped the feature enormously and led to something the community overwhelmingly supported, predestined or not.
There’s a natural human tendency to remember contentiousness, but I’ve heard this complaint about last year’s proposals before, and it just doesn’t match what actually happened. There were some contentious proposals last year, and they were rejected. There were also some complex proposals, like property wrappers, that received extensive discussion and were greatly improved through it. And then there were several proposals that just sailed through unremarkably.
I do think it’s fair to criticize the Core Team for accepting the addition of function builders without a review, but (1) we’ve been steadily working towards making them a sufficiently general feature for proper review ever since and (2) it’s really the only result from that era that seems procedurally backwards at all to me.
No, that is not the point of the core team. The Swift project was meant to be an exercise in developing in the open. To your point about function builders, its surprise announcement at WWDC was irregular and precisely what should not be repeated. It is unlikely that the community, at least in the form it takes today, would be viable after additional such surprises.
Pedantic point, but function builders aren't actually formally part of Swift - the attribute is still underscored, and it hasn't gone through evolution.
Well, but something to that effect is unavoidably part of the language now, no matter how it actually appears ultimately. The details are up for debate, but at least part of the impact is not. That's all I meant.
Speaking as a critic, I think that’s fair. There was a somewhat related issue in the opaque return types proposal where the “Shape” motivating example wasn’t very compelling before SwiftUI was announced, and it was (and remains) hard to come up with many other use cases that don’t involve constrained associated types. This wasn’t a procedural problem, though, just friction caused by secrecy.
@John_McCall, in connection with the review of a feature which Apple strongly desires for a yet-to-be-disclosed project, would it be feasible for the Core Team to make that fact known while continuing to maintain secrecy about the project? I believe the vast majority of the community would appreciate it, and would respect Apple's business needs. Yes, some would grouse about the secrecy of the use case, and in some cases, the pressure would rise to provide more information about the use case. But, all in all, it would reduce friction, in my opinion.
It's not even necessary to say it's for a secret project, just admitting up front that there's an internal Apple desire for a feature and so the process may be different would go a long way to lessening the surprise many would feel.
, wait and 
. 