Welcome back to the weekly brief! We had a great week at WWDC this year! A lot has happened since last issue. The first developer preview for Swift 3.0 was announced, as well as Swift 2.3. Be sure to checkout the official migration guide for moving your Swift 2.x code to Swift 3. Warning: it will be a bit overwhelming, but it will be worth it! Apple also released an Xcode 8 beta, along with beta OS releases for each of Apple’s platforms. And finally, the Swift Programming Language iBook has been updated for Swift 3 beta. You can also download the ePub directly from Swift.org.
While there weren’t any surprises for the language itself announced at WWDC, Apple did announce playgrounds for iPad! I think we’re all very excited about this. 😄
I was lucky enough to attend the conference and was able to meet most of the Swift Core Team. It was great to meet them in person, as well as all of the other developers attending! It was a really great week. Hope to see you next year! 🤓
- SR-1802: Swift
enumcases are exposed to Objective-C with lowercase naming instead of title-case
- SR-1872: Instead of polling every tenth of a second, modify
XCTestCase.waitForExpectations(withTimeout:file:line:handler:)to use a runloop source. This task can be done entirely in Swift – no C++, Python, or CMake knowledge required. 😊
Support for running the Swift test suite on Android was merged during WWDC, and there are a lot of improvements that can still be made. If you have an Ubuntu 15.10 development environment and an Android device, these may be a great way to get started to contributing to Swift on Android:
- SR-1748: Make it possible to run the Swift test suite on an Android emulator, instead of a real device.
- SR-1749: Allow contributors to run only tests that require an Android device, or all the tests that don’t require one.
- SR-1835: Fix a test failure that occurs when referencing
- SR-1836: Fix several reflection test failures on Android, by addressing a linker error.
There were a number of sessions at WWDC this year about Swift, LLVM, and related topics. Below are all the videos relevant to this community. There’s something here for everyone, whether you are a beginner, already have commit access to Swift, or just want a refresher on the upcoming changes in Swift 3. Enjoy!
- Session 207: What’s New in Foundation for Swift
- Session 402: What’s New in Swift
- Session 403: Swift API Design Guidelines
- Session 404: Getting Started with Swift
- Session 405: What’s New in LLVM
- Session 412: Thread Sanitizer and Static Analysis
- Session 415: Going Server-side with Swift Open Source
- Session 416: Understanding Swift Performance
- Session 720: Concurrent Programming With GCD in Swift 3
Commits and pull requests
Brian Gesiak merged adding Android testing support.
Jordan Rose merged changes to prevent treating Swift methods named “init” as Objective-C ARC init methods.
Austin Zheng rewrote native hashed collection indices to provide a number of improvements to
Erica Sadun opened a pull request that adds a “macOS” alias for conditional compilation blocks.
Daniel Dunbar merged changes to SwiftPM to migrate off of
Robert Widmann opened a pull request on SwiftPM to update for using
Ankit Agarwal added C language support in tests for SwiftPM.
Slava Pestov merged work on preliminary SILGen and IRGen support for nested generic types.
Brian Gesiak opened a pull request to allow only static libraries to be built. This enables more finely grained build options.
The feedback from the community on this second round was light, which indicates that the extensive iteration on earlier rounds brought this to a good place. The core team discussed other possibilities for the parameter label (e.g. from: instead of describing:) but ended up agreeing that a more explicit “describing:” label is the best fit for this API.
Many thanks to Austin Zheng and Brent Royal-Gordon for driving this discussion, iterating on the design, and writing a great proposal! I filed SR-1881 to track implementation of this work. This would be a great project for someone who wants to work on the standard library.
Anton Zhilin’s proposal, SE-0077: Improved operator declarations, was returned for revisions. The core team outlined a number of issues that they would like addressed in the revision. Follow the link for the rationale if you’d like to read more.
The core design proposed is a clear win over the Swift 2 design, but the core team feels that revisions are necessary for usability and consistency with the rest of the language…
Proposals in review
Upon accepting SE-0096, the core team renamed the proposed stdlib function from
type(of:)to better comply with Swift’s API guidelines. This proposal renames
alignOfto emulate SE-0096’s example.
We should remove the rarely-used
@noreturnfunction type attribute and instead express functions that don’t return in terms of a standard uninhabited type.
The current default of closure arguments to functions (i.e., arguments to functions that themselves have function type such as
(T) -> U) is to be “escaping”, meaning they can escape the function body such as saving it to a field in a struct or a global variable. In order to say that a closure argument cannot possibly escape the function body (“non-escaping”), the developer must explicitly add an
@noescapeannotation to the argument type.
This proposal switches the default to be non-escaping and requires an
@escapingannotation if a closure argument can escape the function body. Since the escaping case can be statically detected, this annotation can be added via an error with a fixit. Other annotations that have consequences for escape semantics (e.g.,
@autoclosure(escaping)) will be altered to make use of the new
protocol<>construct, which defines an existential type consisting of zero or more protocols, should be replaced by an infix
&type operator joining bare protocol type names.
This proposal cleans up Swifts integer APIs and makes them more useful for generic programming.
Swift’s integer protocols don’t currently provide a suitable basis for generic programming. See this blog post for an example of an attempt to implement a generic algorithm over integers. […]
Finally, the current design predates many of the improvements that came in Swift 2, and hasn’t been revised since then.
This proposal removes
for-inloops, where they are better expressed (and read) as
Chris Lattner posted another message on Swift 3 vs “additive” proposals. This is great reminder to the community to stay focused on finishing Swift 3. While we don’t know the exact deadline for Swift 3, we do know that it is fixed with the final release of Xcode 8 — which is fixed to the final releases of iOS, macOS, and the other platforms, which are fixed to (likely?) new hardware coming this fall. In other words, there is very little wiggle room for any of these releases to slip. There is a lot of work that needs to be done in just a few months!
As I mentioned before, the Swift 3 release is winding down. There is still time left to make changes, but it is very short. As such, we — as a community — need to stay focused on the goals for this release, principally the goal to get to source stability. It is very important for users of Swift that Swift 3 and the Swift 4 compiler be as compatible as possible. This is important for the continued growth of Swift into new places, like new platforms (which don’t get the benefit of Xcode migration) and Swift Playgrounds.
As such, “additive” proposals will need very strong rationale explaining why they are critical for the Swift 3 release, and we won’t be merging these proposals into the swift-evolution repository unless they have that. We should stay focused on proposals that perfect the features we have, rather than adding new ones.
Similarly, general discussions on this mailing list about blue sky additions to the language are distracting from our important goals, and the core team generally isn’t paying attention to these anyway. I would really appreciate it if we could stay focused on what is important, until the time is right to look beyond Swift 3. This time is in August (which will be here way too soon :-), at which point we can look to the future. I outlined this here earlier.
Sorry to be a “downer”, but Swift 3 really is a very important release for the Swift developer community as a whole.
And finally — “I tried Objective-C but I found Swift better”. Ha! 😎