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! 🎉👏
Starter tasks
- 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
Submit a task by sending a pull request or opening an issue.
Commits and pull requests
SE-0102 was implemented by Slava Pestov. This replaces the @noreturn attribute with a return type of Never:
// Old
@noreturn func runAndExit() { /* ... */ }
// New
func runAndExit() -> Never { /* ... */ }As part of SE-0086, Process was renamed to CommandLine, and NSTask was renamed to Process:
// Old
let task = NSTask()
task.launchPath = "/usr/bin/echo"
task.arguments = Process.arguments
// New
let process = Process()
process.launchPath = "/usr/bin/echo"
process.arguments = CommandLine.argumentsAs part of SE-0086, OutputStream was renamed to TextOutputStream and NSOutputStream was renamed to OutputStream.
Ayaka Nonaka merged changes to import Objective-C’s @compatibility_alias compiler directive as a Swift typealias.
SE-0131 was implemented by Dmitri Gribenko. This adds a type-erased AnyHashable container to the standard library.
SE-0130 was implemented by Roman Levenstein. This cleans up a number of String initializers.
Dave Liu submitted a pull request to implement starter bug SR-1608, implementing NSStream, NSInputStream and NSOutputStream in corelibs-foundation.
Accepted proposals
SE-0128: Change failable UnicodeScalar initializers to failable by Xin Tong was reviewed and accepted.
Feedback was universally positive, and the proposal is straight forward.
SE-0130: Replace repeating Character and UnicodeScalar forms of String.init by Roman Levenstein was reviewed and accepted.
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.
SE-0125: Remove NonObjectiveCBase and isUniquelyReferenced by Arnold Schwaighofer was accepted.
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!
SE-0127: Cleaning up stdlib Pointer and Buffer Routines by Charlie Monroe was accepted.
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
ObjectIdentifier.unsafeAddressfield.Thank you to Charlie Monroe for driving this discussion forward!
SE-0131: Add AnyHashable to the standard library by Dmitri Gribenko was reviewed and accepted.
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.
SE-0133: Rename flatten() to joined() by Jacob Bandes-Storch was reviewed and accepted.
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.
SE-0134: Rename two UTF8-related properties on String by Xiaodi Wu and Erica Sadun was reviewed and accepted with revision.
This proposal has two parts. The core team approves the first part: “Rename
nulTerminatedUTF8CStringtoutf8CString”. This property is intended for use when interoperating with APIs that take C-stylechar *parameters.For the second part, the proposal suggests “Rename
nulTerminatedUTF8tonullTerminatedUTF8.” 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.utf8CStringproperty.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.
SE-0117: Allow distinguishing between public access and public overridability by Javier Soto and John McCall had its third review (most reviews of any proposal so far!) and was accepted!
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.
SE-0129: Package Manager Test Naming Conventions by Anders Bertelrud was accepted.
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
Testsconvention directory.
Rejected proposals
SE-0119: Remove access modifiers from extensions was rejected.
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.
SE-0122: Use colons for subscript declarations was rejected.
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.
Deferred proposals
SE-0132: Rationalizing Sequence end-operation names by Brent Royal-Gordon and Dave Abrahams was reviewed and deferred.
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 Brent 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.
Returned proposals
SE-0126: Refactor Metatypes, repurpose T.self and Mirror, was withdrawn for revision.
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! 🎉
Mailing lists
Ted Kremenek sent an update on the end of source-breaking changes for Swift 3:
Dear friends,
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.
Finally
And finally — they always get this wrong. 😂