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.
It’s been awhile since I last wrote about GitHub stats for the project overall, so let’s take a look!
- 394 contributors
- 33,690 stars
- 4,757 forks
- 4,661 pull requests
- 41,925 commits
- 140 swift-evolution proposals
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!
SE-0107: UnsafeRawPointer formalized Swift’s memory model with respect to strict aliasing and prevented arbitrary conversion between
UnsafePointertypes. When moving to Swift 3, users will need to migrate much of their code dealing with
UnsafePointers. The new
UnsafeRawPointermakes 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
UInt8and the client’s element type at every API transition is difficult to do safely.
A handful of Swift numeric types are bridged to
NSNumberwhen 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
NSRangeby boxing them into
Optionals can be used as values of
Anytype. After SE-0116, this means you can pass an
Optionalto 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
Optionalis intentionally passed into Objective-C as a nonnull object, we should bridge
somevalue by bridging the wrapped value, and bridge
nones to a singleton such as
This would change this code:
To the following:
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. 😎
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.”