Indeed - that’s what I’m asking: since the core team are apparently dissatisfied with trailing closures, is it worth presuming that they’d be in favour of a versioned change to fix them?
Please read the section of the post titled "Mandating argument labels by default" for an answer.
I think it makes sense to not bump the Swift version for this change on its own. But does the quoted statement also rule out the possibility of a future new language version that gathers together multiple "smaller" changes like this one and bundles them together in an effort to "smooth out" known rough spots, or including it in a new language version that was already going to include other breaking changes that would add new features?
In other words, if the Swift team at some point in the future decides to bump -swift-version, should the community be prepared to treat that as a limited opportunity window to aim to get changes like these accepted?
8 Likes
Building on this: while non-core APIs aren't in the scope of the language's source compatibility, any language feature introduced needs to consider how API authors will be able to migrate to a new feature in a source-stable way.
For example: suppose we introduce a @nontrailing attribute, which allows the API author to forbid an argument being called using a trailing closure:
Binding.init(
get: @nontrailing @escaping () -> Value,
set: @nontrailing @escaping (Value, Transaction) -> Void
)
Introducing @nontrailing would be a source breaking change by the API author, but it would be their choice, not something imposed on them by an update to the language version.
This is distinct from, say, stating that arguments with labels cannot be trailing as of Swift version 9 — even though the "as of Swift version 9" is versioned, it is imposed by the language and out of control of the API author.
Now, even though it's probably accepted that people writing Binding(get: { ... }) { ... } are bad, the API author might still want to protect them from breakage. So we could take the @nontrailing idea further and allow the API author to version it:
Binding.init(
get: @nontrailing(swift: 9) @escaping () -> Value,
set: @nontrailing(swift: 9) @escaping (Value, Transaction) -> Void
)
1 Like
I don't think introducing a language version should lead to a window of opportunity for small breaks, no. From the source stability principle text:
Having to apply changes may also discourage users from updating to the newer language version, inhibiting adoption of other features.
We want people to update to the newest version as quickly as possible, and a small number of paper cuts impedes this. So language versions should be used for a small number of very important breaks, not a larger number of less important breaks.
(it is of course up for debate which changes are very important and which less so)
2 Likes
There has been some discussion of having a “breaking change” release every 5-10 years in order to give us occasional windows to fix issues like this. Whenever the idea has come up it has been popular and my impression that it was not ruled out. Has that changed? I think this is what @allevato was referring to here. Is Swift really committed to accumulation of cruft forever?
20 Likes
Right, I was thinking of posts like this one from @Slava_Pestov—although he says it's his personal opinion and not the core team's stance, I hope that there could be room for us to correct mistakes at even an extremely limited frequency.
3 Likes
The changes Slava describes here are very different from "en mass" changes such as how labels on trailing closures are treated. He is describing examples that will only cause source breakage on the margin for unusual corner cases. I personally would put trailing closure labels firmly in the "broader rethinking" camp about which he expresses reservations.
1 Like
Cruft is in the eye of the beholder. One developer's important cleanup of cruft is another developer's unnecessary tinkering. We have to strike a balance where we make the language better where it truly matters.
3 Likes
So based on this and the comment just above, it sounds like there may be certain changes that the core team would never consider being significant enough to warrant the churn in code, even in the interest of making the language more consistent/easier to learn, such as certain approaches for trailing closure label improvements, or making argument labels for subscript declarations act the same as all other function argument lists.
If this is the case, might I suggest that it might be beneficial to identify situations like these and add them to something like the Commonly Rejected Changes list so that we at least have this position and the rationale recorded somewhere that can be more easily referenced than forum threads?
11 Likes
Concur. An across-the-board change targeted at requiring a label on the first trailing closure, no matter how incremental, would be a massive breaking change. That said, @xwu's proposal, some sort of attribute and/or other non-source-breaking ideas that have yet to surface could go a long way toward addressing the first trailing closure label issue.
What I really struggle with are (1) existing APIs with multiple closure parameters that were written with a different system in mind, and (2) how to name new functions and their parameters in light of the possibility that nearly any closure parameter could be the unlabelled one.
To those in the community that are proponents of the new syntax, please remind us of some examples of how one should name a function and its parameters where the last two or three parameters take closures. A few good, elegant examples of how that complexity can be addressed might help us skeptics feel more at ease.
3 Likes
It seems that most people posting here are assuming the latter is correct.
I'll instead champion the former. There are many ways people can write confusing Swift. Examples:
- There are 1st and 3rd party functions already that are somewhat confusing when using a single trailing closure [citation needed].
- Functions with multiple optional closures today can be written awkwardly with any of them being the trailing closure and thus missing its label.
We've lived with that without much fuss until now, I argue because the coder can avoid trailing closure syntax when she believes it's more clear. If optional first trailing closure labels are added then that's another option for adding clarity.
Why must we have new enforced hand-holding measures?
Surely auto-completion can be made to not strictly enforce hand-holding, but make it the default; perhaps always inserting the optional first closure label whenever it isn't _:? Won't this the achieve de facto "strict mode"? (Has anyone else been calling it that btw?).
Ok, then have a secondary auto-complete option be the one eliding the label, and perhaps unless a new @noelide attribute is added at the first closure parameter which causes its omission. (Note my suggested attribute affects auto-completion only, the user is still capable of writing valid Swift of which the library author would not approve). I came up with this idea in half a minute, perhaps with some thought some better combination of defaults and attributes can be decided.
I find the SE-027 + optional first closure labels to be the ideal culmination of Swift's initial trailing closure idea. I say give coders some credit and let them decide what is sensible for the code they write. If it means me hitting down-arrow on many occasions to choose the auto-completion eliding the first closure label because it looks better, or even erasing manually it after the fact where I choose, I'd be happy with that. I hope Swift doesn't pull mediocre consistency from the jaws of nirvana on this issue (to mix many metaphors).
I tried to make similar arguments in the SE-0279 thread, probably as poorly as I'm doing here, and of the later posts I saw I didn't see a counter-argument that changed my mind.
- Are there no combination of auto-completion defaults, and attributes to influence them, that will give us good results?
- Are there reason's I'm not seeing such that, in this corner of Swift, we desperately need to prevent the user from circumventing defaults to write code that's a bit confusing?
- Do attributes really need to control what's legal Swift in terms of included labels, not just what's suggested in auto-complete? Would this be an odd new class of attribute or do any do that kind of thing already? (However, this kind of attribute isn't really part of my argument, rather just an idea, and I would be fine with attributes controlling what missing or present closure argument labels were legal)
- Is my base assertion wrong that some confusing code that's written with trailing closures today and expected code post-SE-0279 are basically similar?
- Or are my above cases of existing code I claim to be similarly confusing simply strawman examples?
If the strict consistency camp is to win this argument, I'd like to see the light and be on board.
Disclaimer: modules and frameworks I'm writing are largely for my own use, I'm not (yet?) the producer of a Swift package with many users who aren't me, or aren't colleagues I code review.
I think there's more to be said wrt treating source-stability as a core Swift Evolution principle (not just, but also, as it applies to trailing closures in particular). I've spoken about holding breaking changes for a source-breaking release every few years here, but I would like to address two other aspects.
I assume that what prompted developers to ask you for source stability was primarily the period of subsequent Swift releases with numerous and wide-reaching source breaking changes. Some of those would iirc even change the behaviour of programs without failure to compile.
This was admittedly annoying and probably left a bad taste in many developers mouths, so I can understand wanting to tread lightly in this area. But I imagine a good bit of that ill will came from the relative suddenness and unexpectedness of these changes.
I also contend that except for very limited examples there is not really such thing as indefinite source stability even were we to keep Swift itself exactly as it is today, forever.
Now, one base assumption I'll make here is that to the developer, breaking language changes are not substantially different in their breaking-ness than breaking changes in APIs. I believe this should hold true with good enough error messaging and documentation.
With that in mind, APIs that programmers use in their applications get deprecated and eventually removed with updates of operating systems and libraries routinely. So if developers update their OS and dependencies, they will at some point have to change their source code to keep it in working order, even without changes to the language itself (should developers choose not to update OS and libraries, then they will probably also not update their compiler, so breaking language changes would not affect them).
Since API deprecations and removals are a widely employed tactic all over the industry (heck, even Java removes old, superseded APIs once in a while), I don't really see how a properly managed cycle of deprecation, then removal, of old APIs and syntax could not be adopted in Swift without angering or taxing developers too much.
Like I said in the post I linked above, I think Rusts editions are a good precedent, and I believe a strategy somewhat like the one I'll sketch out here would be beneficial in keeping Swift fresh, modern and cruft-free (especially for beginners that are learning Swift for the first time), while also being slow-paced and predictable enough to satisfy developers preferring slow-moving code-bases:
- We hold breaking changes for a new source-breaking language version that occurs every X (let's say 5) years
- The current compiler supports N language versions before the current one (maybe 2 or 3 which would mean 10 or 15 years of "source stability")
- ABI stability is not affected in any way, and modules using different versions can be used together
- We include warnings giving a very clear picture of the timeline of deprecation/removal of old language versions, so developers don't get surprised and have plenty of time to plan migrations
- With each new language version, we publish comprehensive documentation explaining all breaking changes that needed to be addressed to upgrade to the new version
Bonus points for providing as much automated migration as possible (for most changes I can imagine, such as the one being discussed here, that should be pretty feasible), or, where automatic migration is not possible, generating a list of source locations that need to be looked at by a human. The possibility to migrate a file at a time instead of a whole module at once would also be convenient.
Regarding the choice of X and N, I would believe three older versions and five years, so 15 years total (if you wrote your code just before a new language version is released, up to 20 in the luckiest case) to be ample time (N=2 would probably also do), but Rusts documentation commits to supporting all editions forever so just maybe that is also something that could be considered. While it certainly smells of introducing language dialects more than the case where old versions are eventually to be dropped, I would still prefer that over never ever fixing bad decisions at all.
One thing I haven't put much thought into, because I don't know the workings very well is how this would work with the textual representation of library interfaces (is that still a thing even?). This might throw a spanner here, but I hope/suspect that is something that could be made to work (and it also only affects a subset of syntax constructs anyway).
This is a huge wall of text so apologies for that, but I really would like for Swift to (eventually, even if it means waiting several years for changes) stay modern, without decades of cruft and "if only we could have"s, and—maybe most importantly—easy to learn (because, let's be real, where "actively harmful" begins, novice programmers have already been quite confused and frustrated by inconsistencies/weird quirks)
I also think it might be beneficial to set a precedent and get developers used to minor source-breakage every now and then for when we eventually find a thing that is considered actively harmful and requires a bigger source-break, lest we end up with a Python2/3 situation.
I guess I've said quite enough and will shut up about this topic now 
But please give this some more consideration before committing it to be a core Swift Evolution principle.
28 Likes
This doesn’t really answer the question though. Is the core team open to infrequent windows where we can batch together breaking changes that may otherwise not be accepted? Each individual change would still be subject to evaluation. It would not be a free-for-all. The question is whether or not this opportunity is likely to occur at some point in the future or not.
Swift was given a relatively limited period during which to learn from real world experience and accept breaking changes. IMO, this has left the language in a place where there would be meaningful benefit in eventually accepting at least one more round of breaking changes. (Swift 10?)
31 Likes
I'm in favour of a high bar for source-breaking changes. They shouldn't come willy-nilly. However, I think the current bar is far too high.
If we value Swift's long-term success, we need to cater to developers' experience in the decades to come, instead of appeasing those few who do not wish to maintain their code written in the past 3 years. Codes are supposed to be maintained, after all.
Firmly holding onto past mistakes and backward compatibility will lead to the language becoming unfriendly to newcomers. It will mean adding documentation to inform future generations of all the pitfalls and inconsistencies, just so they can use the language in the unfortunately unintuitive way. In addition, not addressing the mistakes directly and invent workarounds instead will just weigh down the language and make it unswifty.
Microsoft Windows should be a good example for why an unwavering commitment to backward compatibility is a bad idea: It's so backward compatible that "con" is an invalid file name and 1900-02-29 is a valid date in the system, and all for the sake that a few decade-old DOS programs can run smoothly.
If the Swift evolution process is in any way inspired by the natural evolution, then bad designs must die and be replaced by more suitable ones, otherwise we would all still have tails and grabby feet.
33 Likes
Yep, totally agreed.
The goal is to work up the principles outlined above, plus others as they emerge, into a standing document that captures some criteria by which proposals can be evaluated. Whether a proposal is viable should be a question of applying the principles (in addition to evaluating the merits of the proposal itself). That document might include examples, like the inconsistency with subscript labels, but only to explain the application of the principles, rather than as a non-exhaustive repository of things we've said shouldn't be changed. That is, we need a document on how to fish, not a list of fish.
2 Likes
Great post! I can't agree more …
If we can agree on this approach, wouldn't it be good to switch to SemVer versioning for Swift at the same time? We have an example in our eco-system where this works well: GitHub - apple/swift-nio: Event-driven network application framework for high performance protocol servers & clients, non-blocking. There you can see in the issues what will be in the next major version of the library and can prepare yourself accordingly. So: Swift 5.x stays without breaking changes and in Swift 6.0 there will be breaking changes again after a long time of advance notice. This also means that the Swift 5.x series will be continued for a while, so Swift 6.0 will not be coming soon but we will have Swift 5.4, 5.5 and so on. Does that sound like a reasonable plan?
2 Likes
Two other principles I'd like to see addressed are, for lack of better terms, designability (ability of API designers to use the feature) and usability (ability of users to use the feature). These are both related to clarity in many ways but manifest differently. I mention them both at the same time because they affect each other.
Designability
Designability, as a principle, can be, at least partly, considered as the difficultly of applying the Swift design guidelines while using a feature. In general it could be considered the difficultly of building great APIs. Trailing closures have long been an issue in this regard, as they required a special exception to the "put non-defaulted parameters before defaulted parameters" guideline. Additionally, API designers had to take special care when building APIs with multiple closures, especially when there were multiple non-defaulted closure parameters. This was exacerbated by Xcode's non-configurable completion of trailing closures, leading the community to build their own style guides, as well as linters and formatters, which forbade the use of trailing syntax with multiple closures.
0279 is a mixed blessing in this regard. While it answers the question of what multiple closures at the end of a method could look like, it further complicates the defaulted vs. non-defaulted arguments issue, while keeping the issues around the single trailing closure. Additionally, given the limitation of the backward parsing syntax used for the multiple trailing closure syntax, it's very difficult for API designers to anticipate how users will use their API. For example, in the multiple closure case, if the user keeps the default values for all but the first parameter, the trailing syntax doesn't work at all.
func multipleClosure(nonDefault: () -> Void, defaulted: () -> Void = {})
So while using multiple closures here works fairly well:
multipleClosure {
} defaulted: {
}
If the user accepts the defaulted parameter by deleting the second closure, they're immediately met by a compiler error due to the conflict between a required parameter and only being able to use the trailing syntax with the second closure.
multipleClosure {
}
So, as a designer, I'm stuck. It's impossible to design an API that works well with both the multiple trailing syntax and the single trailing syntax.
But wait, there's more! If both parameters are defaulted, the user may think they're providing the first closure but it's actually the second due to the existing trailing closure syntax. I'll bring this up again in the Usability section, as I think it's a serious user issue as well. But in addition to the few closure case, there are issues in how to design APIs with a mix of multiple non-defaulted and defaulted closures, as well as all defaulted closures, which have been brought up before. This is all something an attribute can't fix.
One possible solution would be multiple similar methods based on which closure parameters are used, but I'm loath to return to Objective-C's solution to this problem. Such a solution is also a major usability issue due to the cognitive overhead of many similar methods.
In summary, there doesn't seem to be a way to design an API using multiple closures that fulfills Swift's ideals while also being usable.
Usability
On the flip side from designability is usability, or the ability of users (in this case, API consumers) to use APIs designed for trailing closures.
In the previous trailing closure case this was pretty straightforward, especially if the closure was intended as a completion handler, where the lack of a label wasn't usually a problem. It was a binary choice: either you accepted Xcode's completion of the trailing syntax (when it worked), or you entered the closure manually. The multiple closure case was complicated by Xcode's default acceptance of the trailing closure, meaning many users may accept sub-optimal API usage, but the community's style guides, linters, and formatters were able to largely control the issue. Multiple closures used the non-trailing syntax and trailing syntax was largely used by completion handlers.
0279 can improve the usability of the multiple closure case, but introduces a couple edges that will likely catch users by surprise. First and foremost, the first closure parameter can only be used unlabeled if at least one other closure is also used, otherwise the syntax defaults to interpreting it as the final closure. Not only is this likely to be a surprise to users, as it's the only bit of Swift syntax that behaves like this, but it's Xcode's default behavior. In the above example, if the user hits return to autocomplete the first closure, Xcode will complete both. If the user then fills in the first closure but deletes the second because they're happy with the default, they'll get a compiler error, merely from deleting apparently optional code. This is even worse when both parameters are defaults. In that case, and if the closures have the same signature, the closure is silently interpreted as the second closure instead of the first. Personally, this sort of dangerous, silent behavior change outweighs any theoretical consistency between the multiple and single trailing closure cases. By keeping the unlabeled case solely for the trailing closure, any ambiguity can be avoided and both versions of this issue cease to exist.
Second, though far less harmful, are just the general ergonomics of the new multiple closure case and how it interacts with autocomplete. There seem to be two versions offered to the user: a full completion with every closure, and just the trailing case. For the sorts of APIs 0279 is supposed to enable, it becomes a tedious case of whack a mole with unwanted, defaulted parameters. Ignoring for a moment the more dangerous edge above, forcing the user to manually remove parameter they don't want is tedious and often leads to them unwitting passing all parameters, even if they're just passing the defaults again (I see this all the time in the Alamofire usage of inexperienced users). Of course, this is a more general issue with Swift's autocomplete, as it should offer more combinations of methods with defaulted parameters, but as a design principle, a language feature which exacerbates a well known tooling issue should be avoided.
Conclusion
Designablility and Usability are two sides of the same coin. They aren't usually brought up in Swift evolution because it's rare that a feature would impact them so deeply, but they're always there. Trailing closure syntax has a significant impact on the appearance and ergonomics of Swift as a language, so it's important, critical even, that it can satisfy both.
16 Likes
The Goal
My goal for Swift has always been and still is total world domination. It’s a modest goal. -- Chris Lattner, June 30, 2017
An Important Part of the Path to the Goal
Swift 3 pivoted about halfway through: the main goal changed from ABI stability to source stability. And I think that was totally the right thing to do. … What we realized halfway through the Swift 3 development cycle was, as the community is growing and as more and more people are writing more and more code, not breaking that code became really important. … One of the reasons we started out by saying that Swift is not source-stable is that we knew that before the open-source release we didn’t have the benefit of lots of people debating, discussing, arguing, and bikeshedding. And you really need that to make something great. -- Chris Lattner, June 30, 2017
How People Pick a Programming Language
Everyday, people make decisions about which programming language to use for a project. They consider many factors, including backward compatibility.
For people that manage money, backward compatibility of a programming language is important because it lowers the cost of maintenance in the near to middle term.
For people that manage risk, backward compatibility of a programming language is important because it reduces the chances of real world harm and financial losses caused by bugs that come with new versions and migration.
For people that manage enterprise-scale products, backward compatibility of a programming language is important because it reduces the frequency of updates and disruptions for their customers.
...and so on...
Nearly all of the people making those decisions care not one whit about whether a trailing closure is labelled. They would be very upset by the notion that requiring a label on a trailing closure might put their budgets, their missions, their products and their customers at risk of migration bugs. They would think of Swift as being risky or unreliable.
So, we need to work very, very hard to find creative and brilliant ways to improve what we have without breaking what they have. Otherwise, those people won't allow Swift to be used for their projects, and Swift won't make the leap to wide-spread adoption.
The Core Team Has No Choice
And, like it or not, that is why the Core Team must take such a firm stance against breaking changes. I would imagine that the Core Team, in their heart of hearts, want to make changes and to make Swift shine even brighter than it does already. But, they are responsible stewards, and will do what needs to be done to achieve the goal. We should applaud them.
3 Likes