I agree. I think what many of us would appreciate is just honesty. Be honest about the motivations behind a feature (e.g. "teams within Apple really want it"), be honest about time pressures (e.g. "we need to get this into Swift 5.3, despite it being branched already"), just be honest. Then there won't need to be "conspiracy theories" (is it really a theory when it's a pattern that's been repeated for years?) about why changes were made. Otherwise you're going to see this type of reaction every time a change is accepted that doesn't seem fully justified.
10 Likes
As an aside, I'd disagree here. A new syntax isn't additive when Xcode defaults to completing that syntax, regardless of the context. It isn't additive when Apple adopts it across their API and sample code. It isn't additive when the naming guidelines have to be updated. When it becomes the new "Swifty" way of doing things, it isn't additive.
14 Likes
You are right. My frustrations with the overall tone of this thread got the better of me. My apologies for that.
Doug
41 Likes
I think the core team has been relatively clear where they stand, though of course when it comes to communication there is always room for improvement. I think this experience will inform and improve the evolution process in the future.
In case it's helpful to anyone else, this is my own summary of the core team's responses:
Whether a change is justified / worthwhile / too small / should even be considered
While there is not universal agreement on the motivation, I just wanted to note that at the very least the core team clearly expressed their opinion on the matter up-front.
Problems with the existing single trailing closure syntax
I also appreciated this up-front acknowledgement, which I agree with:
Expanding on that (emphasis mine):
Speaking for myself, I'd be very interested in exploring adding such an annotation, as I think it could be very useful. Though I agree that it would be best to have a separate, more focused pitch for that.
Supporting optionally allowing a label for the first trailing closure / better support for "co-equal" closures
This is one of the biggest areas of feedback. The core team has not ruled this out:
Ben agrees that they are open to an additional proposal to consider this, and adds that part of the reason to consider it separately is that it expands the scope of the proposal to also impact single trailing closures, and since it would be optional, wouldn't impact the current proposal:
FWIW, regarding whether this feedback was carefully considered:
Speaking for myself, I think this proposed extension is worth more consideration, but I don't agree with characterizations that optionally allowing a label on the first closure is obviously better and a trivial extension to the proposed API. It adds a third way to write multiple trailing closures (don't use trailing syntax at all, use trailing syntax without a leading label, use trailing with a leading label), which may be a worthwhile thing to do, but not obviously worthwhile, and so worth a separate discussion.
Migrating to a future where we can require a label for the first trailing closure
The core team has deep concerns about this, but hasn't entirely ruled it out (emphasis mine):
Further clarification:
Speaking for myself, I don't feel that the suggested "unlabeled closure parameter == unlabeled trailing closure, and vice versa" rule is obviously correct, and I have specific, concrete concerns that I'd be open to discussing in more detail. However, since the core team has not ruled out considering such a rule, I think it would be best to discuss that in a separate pitch thread.
Updating the API naming guidelines
The suggested change to the naming guidelines are meant to clarify existing, implicit guidance, and aren't specific to multiple trailing closures:
However, Ben did acknowledge the following:
Revising existing APIs (i.e. changing the Standard Library)
Nothing is being renamed now, and any potential renames would need new proposals:
Of course, like any language addition, this proposal will have an impact on the design of new APIs.
Implications on tooling (i.e. autocomplete in Xcode)
AFAIK the core team has not responded to this feedback, but speaking for myself: since the tools are always being improved and can change more freely than the language, I'm sure that Apple would welcome a separate discussion with suggestions for how to improve the tools, especially for existing pain points, since that is valuable feedback.
And finally: regarding healthy discourse
I just wanted to echo this. If a decision is characterized as obviously wrong, and the motivations for the decision are characterized as obviously not primarily coming from a genuine desire to do what's best for the language, then people who agree with the decision are chased away for fear of being vilified, and the lack of their voices then wielded as further evidence against the decision.
To be clear, many people have avoided making those characterizations (thank you!) — I just think this is worth keeping in mind.
47 Likes
Very balanced response, thank you.
2 Likes
That's a concern for sure.
The accepted proposal has the merit of being a simple extension of the existing trailing closure syntax. It has the downside of hiding a label that probably shouldn't be omitted in some situations.
It's easy to spot places where a new feature doesn't work well, and it's a good idea to adapt the feature to better handle those cases when possible. But by focussing entirely on problematic cases during review I feel we're painting a gloomier perspective than reality. And by trying to address them all, there's a real risk of getting overboard with special rules or optional syntactic elements.
Overall I think the proposal as accepted is relatively well balanced. It does not handle everything perfectly, but handling everything perfectly requires more complexity which can be added later if needed.
This clearly took a lot of time and effort to compile and write. What a great post. Thank you!
1 Like
Earlier, I had taken the core team's response to mean that alternatives were considered and the final design prevailed. But as you summarize:
If virtually every piece of review feedback on a proposal is to be deferred to a separate discussion, what was the point of the review as a step in the Swift Evolution process?
8 Likes
I think you need to separate feedback into "yes, and" and "no, because" buckets.
The core team feels that SE-0279 is an improvement to the language that stands on it's own, and so can be accepted. But there are potential further directions that could be explored, building on this proposal. This is what you might thing of as the "yes, and" (perhaps "yes, and maybe") interpretation of the proposal.
Some of these future directions are more challenging. They change the shape of the language in a way that might not be ok. Hence "we are not ready to completely rule [them] out, but it would need a very strong source-compatibility and migration story". So the right next step if anyone wants to pursue this is to open up new threads discussing how they might be achieved, while being mindful of the guidance that it may be a long shot. Depending on how these play out, SE-0279 is either the final state of this part of the language, or an acceptable resting state that we move on from in a later release. Either of those is an acceptable outcome.
Now, others disagree. They think of these enhancements as "no, because" only with future enhancements would a change like SE-0279 be acceptable. This is a fine position to take, but not one the core team agrees with (or we would not have accepted the proposal).
32 Likes
Thank you for this clarification @Ben_Cohen.
2 Likes
A concern is what could happen if we do eventually optionally allow the first trailing closure's label to be mandatory. Let's call that followup completion proposal SE-YYYY. If there's API can could benefit from SE-0279, but benefit better from SE-YYYY, then we have to advise to hold off on that API rename so we don't have the churn of renaming a method twice in succession. (Or worse, don't do it and be stuck with a not-as-good API name forever.)
I wonder: Is SE-YYYY feasible to do? And how soon could it be done? It probably have to be at one Swift release after the one for SE-0279.
This review felt similar to last year's SE-0255 review of implicit return. Supporting SwiftUI's syntax provided a massive, but undisclosed, motivation for eliding return. It would have been nice to know about that motivation during the review process. Or, at a minimum, it would have been respectful for Apple to say to the community, "This sugar is quite helpful to a new framework that we are pursuing. Unless you show us that this sugar is fatally flawed, we plan to move forward with it. Please let us know whether we are about to step on a landmine."
I don't know whether this review is of the same sort, but, if it is, a bit more transparency about motivations would have been appreciated.
22 Likes
Thank you for taking the time to explain the core team's thinking here.
You state that there are a variety of future directions (such as what to do in the future about labeling the first trailing closure) that "we [the core team] are not ready to completely rule out." Therefore, the core team should strike that portion of the proposal text which explicitly rules out certain of these future directions from the accepted version. As it stands, the core team is both saying that those directions are not ruled out, but have accepted without revision a proposal which states that they are.
3 Likes
John_McCall sez:
I think we’d like to get some actual living experience with this design before considering a revision, but yes, it was intentional that we picked a design that can extended in that way in the future.
I think it’d be nice if we could label the first closure, but, also, it makes sense to me to try this way out and add that in if we decide we like it, as John says.
I do worry about these flame wars. The Core Team is made up of humans and it’s tiring as heck to have everyone calling your motives into question for every decision you make. Swift is a noble experiment in developing in the open and so far it’s given me both my favorite programming language and favorite runtime library.
What I believe we’d all love to see is Swift’s open model used for more of Apple’s APIs, so we could avoid having a bunch of new, limited-use, unasked-for, barely-working, semi-magical, non-extensible, and undocumented API changes to AppKit and UIKit and Foundation dumped on us all at once every year, with a shrug of the shoulders when we we ask if they can fix them, “Sorry, we froze the APIs six months ago."
But when I bring this up with Apple’s top management, one of their responses is, hey, the Swift team spends a LOT of time just trying to interface with the community, and it’s exhausting. (Another is, WOW does the public get resentful when we announce something and then aren’t able to ship it.)
If we emotionally punish the heck out of the Core Team for every decision we don’t like, the experiment in openness will end. Maybe we’d have two Swifts then — OpenSwift and Apple Swift — but that would be to everyone’s detriment.
-Wil
18 Likes
I find it ugly. I hope the label on closures will be added (forced or optional).
Better would be to change the trailing closure syntax in the future for single trailing closures and multiple trailing closures to force labels.
Some bad things, even though they are established have to be done. Maybe not now, but gradually over time. Adding labels for closure parameters in the near future and forcing labels in the far future.
It sounds a bit like self censuring to me.
Especially if this suggests that we could not discuss options and decisions taken by the Core Team.
1 Like
I suspect you mean “self-censoring”, as “censure” is what the community is currently doing to the Core Team.
But I’m not asking for the former (although some participants here might want to consider it), I’m asking that the latter be toned down, because trailing closure syntax just isn’t worth a giant flame war where we pick apart every statement anyone on the team ever said.
-Wil
4 Likes
Then I agree, the debate is getting too emotional.
1 Like
I had a long reply typed out but I'll just boil it down: I think this mischaracterizes the vast majority of this thread. I think this topic has turned up quite a few important issues, including issues with the acceptance and proposal itself (insofar as integrating community feedback and outlining next steps), possible ways to integrate the syntax (and the issues in doing so), and issues with the evolution process itself. To summarize it as a "flame war" does a disservice to the community (and flame wars) and those who spend their free time honestly trying to improve Swift. Things seem to have settled at a simmer for now, so I guess all that's left is waiting to use the new syntax and the upcoming guideline discussion.
21 Likes
For those who haven't already seen it, @xwu has started a thread with a draft proposal to add support for the use of an optional label for the first trailing closure.
19 Likes