Of course, the big news this week was the Apple Event yesterday. The iPhone 7 was announced, along with Apple Watch Series 2. But more importantly, the GM seeds for Xcode 8, iOS 10, macOS 10.12, watchOS 3, and tvOS 10 were released — and that means we have our Swift 3.0 GM release. However, this still hasn’t been posted to Swift.org.

The public releases of iOS 10 and macOS Sierra will be September 13 and September 20, respectively.

Stats

It’s been awhile since I last wrote about GitHub stats for the project overall, so let’s take a look!

Commits and pull requests

John Holdsworth opened a pull request to port corelibs-foundation to Android. 🎉 This is a great step towards making Swift on Android useful, and potentially sharing code across platforms.

Anders Bertelrud improved Xcode project generation in SwiftPM. “This is a first version of a more layered, robust, and readable Xcode project generation. The idea is to provide a simple representation of the Xcode project model, so that the logic that creates a project is readable, understandable, and maintainable.”

Jacob Bandes-Storch improved diagnostics for invalid operator declarations.

Proposals in review

The following proposals definitely address some pain points in Swift 3 and it would be great to seem them accepted and implemented!

Andrew Trick’s proposal, SE-0138: UnsafeRawBufferPointer is under review. This is a purely additive proposal to improve the Swift 3 migration experience.

SE-0107: UnsafeRawPointer formalized Swift’s memory model with respect to strict aliasing and prevented arbitrary conversion between UnsafePointer types. When moving to Swift 3, users will need to migrate much of their code dealing with UnsafePointers. The new UnsafeRawPointer makes that possible. It provides a legal means to operate on raw memory (independent of the type of values in memory), and it provides an API for binding memory to a type for subsequent normal typed access. However, migrating to these new APIs is not always straightforward. It has become customary to use [UInt8] in APIs that deal with a buffer of bytes and are agnostic to the type of values held by the buffer. However, converting between UInt8 and the client’s element type at every API transition is difficult to do safely.

Joe Groff’s proposal, SE-0139: Bridge Numeric Types to NSNumber and Cocoa Structs to NSValue, is under review.

A handful of Swift numeric types are bridged to NSNumber when passed into Objective-C object contexts. We should extend this bridging behavior to all Swift numeric types. We should also bridge common Cocoa structs such as NSRange by boxing them into NSValue objects.

Another proposal by Joe Groff, SE-0140: Bridge Optional As Its Payload Or NSNull is under review.

Optionals can be used as values of Any type. After SE-0116, this means you can pass an Optional to an Objective-C method expecting nonnull id. This is often a mistake, and we should raise a warning when it occurs, but is occasionally useful. When an Optional is intentionally passed into Objective-C as a nonnull object, we should bridge some value by bridging the wrapped value, and bridge nones to a singleton such as NSNull.

This would change this code:

let s1: String? = nil, s2: String? = "hello"
// works, should warn, currently produces an opaque object type
ObjCClass().imported(s1)
// works, should warn, currently produces an opaque object type
ObjCClass().imported(s2)

To the following:

let s1: String? = nil, s2: String? = "hello"
// proposed to bridge to NSNull.null
ObjCClass().imported(s1)
// proposed to bridge to NSString("hello")
ObjCClass().imported(s2)

Mailing lists

Still not much activity on the lists! Everyone must be busy preparing their apps for iOS 10 and macOS Sierra, or maybe everyone is distracted by that shiny new iPhone 7. 😎

Finally

And finally — 😂

“Try to realize the truth, there is no compiler. Then you will see it is not the compiler that’s broken, it is only yourself.”

— @NeoNacho