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
<https://github.com/apple/swift-evolution> repository):
SE-0025 - Scoped Access Level
<https://github.com/apple/swift-evolution/blob/master/proposals/0025-scoped-access-level.md>
SE-0042 - Flattening the function type of unapplied method references
<https://github.com/apple/swift-evolution/blob/master/proposals/0042-flatten-method-types.md>
SE-0045 - Add scan, prefix(while:), drop(while:), and iterate to the stdlib
<https://github.com/apple/swift-evolution/blob/master/proposals/0045-scan-takewhile-dropwhile.md>
SE-0068 - Expanding Swift Self to class members and value types
<https://github.com/apple/swift-evolution/blob/master/proposals/0068-universal-self.md>
SE-0075 - Adding a Build Configuration Import Test
<https://github.com/apple/swift-evolution/blob/master/proposals/0075-import-test.md>
SE-0077 - Improved operator declarations
<https://github.com/apple/swift-evolution/blob/master/proposals/0077-operator-precedence.md>
SE-0080 - Failable Numeric Conversion Initializers
<https://github.com/apple/swift-evolution/blob/master/proposals/0080-failable-numeric-initializers.md>
SE-0081 - Move where clause to end of declaration
<https://github.com/apple/swift-evolution/blob/master/proposals/0081-move-where-expression.md>
SE-0082 - Package Manager Editable Packages
<https://github.com/apple/swift-evolution/blob/master/proposals/0082-swiftpm-package-edit.md>
SE-0088 - Modernize libdispatch for Swift 3 naming conventions
<https://github.com/apple/swift-evolution/blob/master/proposals/0088-libdispatch-for-swift3.md>
SE-0089 - Renaming String.init<T>(_: T)
<https://github.com/apple/swift-evolution/blob/master/proposals/0089-rename-string-reflection-init.md>
SE-0092 - Typealiases in protocols and protocol extensions
<https://github.com/apple/swift-evolution/blob/master/proposals/0092-typealiases-in-protocols.md>
SE-0096 - Converting dynamicType from a property to an operator
<https://github.com/apple/swift-evolution/blob/master/proposals/0096-dynamictype.md>
SE-0099 - Restructuring Condition Clauses
<https://github.com/apple/swift-evolution/blob/master/proposals/0099-conditionclauses.md>
SE-0101 - Reconfiguring sizeof and related functions into a unified
MemoryLayout struct
<https://github.com/apple/swift-evolution/blob/master/proposals/0101-standardizing-sizeof-naming.md>
SE-0102 - Remove @noreturn attribute and introduce an empty Never type
<https://github.com/apple/swift-evolution/blob/master/proposals/0102-noreturn-bottom-type.md>
SE-0103 - Make non-escaping closures the default
<https://github.com/apple/swift-evolution/blob/master/proposals/0103-make-noescape-default.md>
SE-0104 - Protocol-oriented integers
<https://github.com/apple/swift-evolution/blob/master/proposals/0104-improved-integers.md>
SE-0107 - UnsafeRawPointer API
<https://github.com/apple/swift-evolution/blob/master/proposals/0107-unsaferawpointer.md>
SE-0110 - Distinguish between single-tuple and multiple-argument function types
<https://github.com/apple/swift-evolution/blob/master/proposals/0110-distingish-single-tuple-arg.md>
SE-0111 - Remove type system significance of function argument labels
<https://github.com/apple/swift-evolution/blob/master/proposals/0111-remove-arg-label-type-significance.md>
SE-0120 - Revise partition Method Signature
<https://github.com/apple/swift-evolution/blob/master/proposals/0120-revise-partition-method.md>
SE-0127 - Cleaning up stdlib Pointer and Buffer Routines
<https://github.com/apple/swift-evolution/blob/master/proposals/0127-cleaning-up-stdlib-ptr-buffer.md>
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.
While the exact details of how we will accomplish this feat are still being
discussed, here is a sketch of how this will likely work in the Swift 4
timeframe. The key enabler is a new compiler flag that indicates the language
version to compile for (e.g., similar to the clang -std=c99 flag). The compiler
flag will be provided by the build system you are using (e.g., Xcode, SwiftPM,
etc.) on a per-module basis:
For language syntax/semantics, the compiler can use the language mode to
properly implement the language version being used by a module.
For the Standard Library, additive and subtractive changes are easily handled
(the former by just adding them, the later by using deprecation techniques).
For semantics changes, things are much more complicated, and will need further
study.
The great thing about this approach is that a single Swift 4 compiler is
building all of the sources in an application. This allows us to roll out this
approach before achieving full ABI stability — something that will be a goal
for Swift 4, but is impractical to achieve for a Swift 3.x release. It also
provides us a general framework in the future for handling source compatibility
as Swift evolves.
To make this more concrete, suppose an application is written to use Swift 4,
but uses packages via SwiftPM that are written using Swift 3. A single compiler
would build both the app and the packages — thus ensuring that all the compiled
sources are binary compatible. It would not be the case that a framework built
with the Swift 3 compiler could be used by an app built using the Swift 4
compiler. That kind of library binary stability (ABI) will be a key goal of the
Swift 4 release.
These constraints mentioned above will serve as scaffolding for Swift 4
development. Discussion about Swift 4 commences on Monday. Ahead of that, Chris
Lattner plans to send out thoughts from the Core team on some of the known key
goals (and non-goals) for the release. In the meantime, the focus over the next
couple days should be taking stock of what has landed for Swift 3 and to see if
any of the proposals mentioned above are close to being completed or are truly
out of scope.
Thank you again to everyone for making Swift 3 such as fantastic release!
Ted
_______________________________________________
swift-dev mailing list
swift-dev@swift.org
https://lists.swift.org/mailman/listinfo/swift-dev
