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! 🤓

Starter tasks

  • SR-1802: Swift enum cases 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 stdout on Android.
  • SR-1836: Fix several reflection test failures on Android, by addressing a linker error.

Submit a task by sending a pull request or opening an issue.

WWDC 2016

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!

Commits and pull requests

Brian Gesiak merged adding Android testing support.

Robert Widmann opened a pull request to implement the fileprivate access level from SE-0025.

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 Dictionary and Set.

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 fputs().

Alsey Coleman Miller implemented the UUID value type in corelibs-foundation for SE-0069.

Robert Widmann opened a pull request on SwiftPM to update for using fileprivate.

Ankit Aggarwal 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.

Accepted proposals

Austin Zheng’s and Becca Royal-Gordon’s proposal, SE-0089: Renaming String.init<T>(_: T), was accepted for Swift 3. 🎉

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 Becca 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.

Returned proposals

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

Erica Sadun’s proposal, SE-0101: Rename sizeof and related functions to comply with API Guidelines, is under review.

Upon accepting SE-0096, the core team renamed the proposed stdlib function from dynamicType() to type(of:) to better comply with Swift’s API guidelines. This proposal renames sizeof, sizeofValue, strideof, strideofValue, align, and alignOf to emulate SE-0096’s example.

Joe Groff’s proposal, SE-0102: Remove @noreturn attribute and introduce an empty NoReturn type, is under review.

We should remove the rarely-used @noreturn function type attribute and instead express functions that don’t return in terms of a standard uninhabited type.

Trent Nadeau’s proposal, SE-0103: Make non-escaping closures the default, is under review.

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 @noescape annotation to the argument type.

This proposal switches the default to be non-escaping and requires an @escaping annotation 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 @escaping annotation.

Adrian Zubarev’s and Austin Zheng’s proposal, SE-0095: Replace protocol<P1,P2> syntax with P1 & P2 syntax, is under review.

The current 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.

A proposal from Dave Abrahams, Dmitri Gribenko, and Maxim Moiseev, SE-0104: Protocol-oriented integers is under review.

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.

Erica Sadun’s proposal, SE-0105: Removing Where Clauses from For-In Loops, is under review.

This proposal removes where clauses from for-in loops, where they are better expressed (and read) as guard conditions.

Mailing lists

Not on the lists, but @practicalswift posted an update on the number of open swiftc crashers. 42 open, 5090 closed. Thanks to Slava Pestov for his hard work on these. 👏

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.

Finally

And finally — “I tried Objective-C but I found Swift better”. Ha! 😎