Issue #32 28 Jul 2016
Written by: Jesse Squires
Yesterday was the big day — the last day for Swift 3 breaking changes! Which means Swift 3 evolution is done!
According to Ted Kremenek’s email (below), any proposals that are in active development and near completion have an extended deadline of Friday, July 29. So, tomorrow! 😄 As of this writing the current status page lists 23 proposals that are “awaiting implementation”, however I know many of these are in-flight. It should be more clear exactly which proposals are not going to be included in the final Swift 3.0 release by the end of the day tomorrow, or early next week.
Unfortunately, it looks like a decent amount of proposals that contain source-breaking changes likely will not make the deadline for Swift 3. This means that Swift still has not reached (complete) source-stability, but it will be a great release nonetheless. At the moment, it’s not clear what the plan is for these proposals. Perhaps one or more Swift 3.x releases will address them?
In any case, Swift 3 is a dramatic step forward for the language. The Swift Core Team and open source contributors deserve a huge congratulations for all of their hard work! 🎉👏
- SR-2083: [SwiftPM] Don’t error if a directory contains only ignored files
- SR-2022: [Compiler] Add better fixit for type checking in switch statements
Commits and pull requests
Ayaka Nonaka merged changes to import Objective-C’s
@compatibility_alias compiler directive as a Swift
Feedback was universally positive, and the proposal is straight forward.
There was very little public discussion about this proposal, but the core team believes this eliminates a real ambiguity, while leaving doors open for future improved designs.
Thank you to Roman Levenstein for driving this discussion forward.
This proposal had significant community feedback to help refine and improve its design, and Arnold has incorporated that into his v2 of the proposal. The core team agrees the new revision is a good design.
Thank you to Arnold Schwaighofer for driving this discussion forward!
The proposal has been accepted with a modification.
This proposal got a significant amount of helpful feedback, which Charlie has already incorporated into the proposal. The core team requests one additional minor change, which is to drop the addition of the
Thank you to Charlie Monroe for driving this discussion forward!
The feedback on this proposal was quite positive. A few questions were raised, but were answered on-thread. Thank you to Dmitri Gribenko for writing this proposal and driving this discussion forward.
This proposal had significant positive community feedback for aligning common operation names, but raised questions about whether ‘flatten’ was term of art, and what it would mean for related operations like ‘flatMap’. The core team discussed both sides of this debate, and decided it is best to rename ‘flatten’ to ‘joined’, but keep ‘flatMap’ as it is, to preserve its term of art. The core team prefers that it remain a distinct overload of joined(separator:) to preserve performance. It also requests that the returned collection types (FlattenCollection and friends) be left as-is for now, since they are not names commonly directly referenced, and we’d like to keep the change minimal.
Thank you to Jacob Bandes-Storch for driving this discussion forward! Time is short, we’d appreciate it if someone could implement this ASAP.
This proposal has two parts. The core team approves the first part: “Rename
utf8CString”. This property is intended for use when interoperating with APIs that take C-style
For the second part, the proposal suggests “Rename
nullTerminatedUTF8.” The core team discussed this, looked at various uses of the API (among code bases publicly available on github) and came to the conclusion that it is best to just remove this property outright. The clients we found would be better served using the
Thank you to Xiaodi Wu and Erica Sadun for driving this discussion forward! Time is short, we’d appreciate it if someone could implement this ASAP.
This proposal was far better received by the community than previous versions of the proposal, and the “first design” was the favored path within it. However, there were some concerns raised about the complexity of the model, stemming from non-obvious combinations like “open private”. As such, the core team has requested that the proposal be revised to make “open” function as another access control specifier. “open” is now simply “more public than public”, providing a very simple and clean model.
John has already revised the proposal to the new model, I encourage you to read it if you haven’t already.
Thank you to John McCall and also Javier Soto for driving this discussion forward! John is already working on an implementation of this now.
There was relatively little feedback on the proposal but it had unanimous support, along with additional support for the future directions that are unblocked by the proposal with regard to allowing additional target types under the
The majority of the feedback on this proposal was opposed to it, because it eliminated the useful ability to apply access control to a batch of methods and properties.
Thank you to Adrian Zubarev for raising this proposal.
The review of “SE-0122: Use colons for subscript declarations” ran from July 19…24. The proposal has been rejected.
The feedback on this proposal from the community was overall divided with a slight bias towards reject. Reasonable arguments were made on both sides: subscripts are definitely property-like in some ways, but they are also function-like in other ways. Further, if we were aiming to align declaration syntax with use, arguably the parameter list should be enclosed in square brackets (but to be clear, we’re not going to do that). Overall, the core team agrees with the pervasive sentiment that this is not important enough to make a change for.
Thank you to James Froggatt for raising this proposal.
This is a very large proposal very late in the Swift 3 schedule. It has some clearly good pieces to it, but also many parts that are controversial with the community, and requires more design and iteration than time permits. It is best to defer this and make a change when we have something truly great, giving the benefit of proper time to design and evaluate the proposal.
Thank you to Becca Royal-Gordon and Dave Abrahams for driving this discussion. When the goals and parameters of Swift 4 are established, we should pick up this thread and see what makes sense to do here.
The authors of SE-0126 have requested that we withdraw the proposal. The idea will be revised, return back to the “pitch” phase, and when that converges, SE-0126 will be revised.
Proposals in review
All proposals for Swift 3 have been reviewed! 🎉
Ted Kremenek sent an update on the end of source-breaking changes for Swift 3:
Today is July 27 — and the last planned day to take source-breaking changes for Swift 3. It has been an incredible ride to this point, so let’s take stock of where we are. Here are the list of currently accepted — but not yet (fully) implemented — evolution proposals (this is drawn from the “accepted” but not marked “implemented” proposals from the swift-evolution repository):
These are all changes the community has approved for Swift but did not make today’s cutoff. Some of these proposals have implementations actively underway. For those proposals already in active development — and near completion — I am okay with extending the deadline for those changes to Friday, July 29. Such changes need to be approved by the release manager (myself) and should be merged into master via a pull request. When creating the pull request, please assign it to me (tkremenek), and mention the pull request on the swift-dev mailing list as well with the SE number in the email title.
The rest of the unimplemented proposals do not make Swift 3. This leaves us with the question of what to do with them. These proposals represent the known and reviewed changes we want to make to Swift, but inevitably there will also be changes that we don’t even know about today that we will want to take into Swift that can impact core source stability. That said, we also have a very strong desire to maintain source compatibility with Swift 3 and Swift 4 as much as possible to provide some stability for which Swift users to build upon. The challenge of course is reconciling these diametrically opposing goals: maintaining source stability while having the ability to incorporate more core (and important) language changes that are possibly source-breaking.
The Swift team at Apple has reflected on this and decided what it “means” for Swift 3 to be source compatible with Swift 4 and later releases going forward. Our goal is to allow app developers to combine a mix of Swift modules (e.g., SwiftPM packages), where each module is known to compile with a specific version of the language (module A works with Swift 3, module B works with Swift 3.1, etc.), then combine those modules into a single binary. The key feature is that a module can be migrated from Swift 3 to 3.1 to 4 (and beyond) independently of its dependencies.
And finally — they always get this wrong. 😂