Welcome to issue 41! Swift 4.0 development continues, and it looks like Swift 3.0.1 Preview-2 has landed.

Community

Brian Gesiak wrote a great article on how Android support came to Swift, Porting the Swift Runtime to Android, Part One: The How. He makes it seem so easy!

Apple open sourced Swift Protobuf, a plugin and runtime library for using protobuf with Swift. Note that it is currently in a prerelease state.

Commits and pull requests

Jordan Rose fixed a bug that prevented @NSManaged properties from satisfying protocol requirements.

As mentioned in Issue 39, Airspeed Velocity numbered and categorized each of the FIXMEs associated with ABI stability. This week, Doug Gregor knocked out 3 of the standard library’s FIXME’s (#35, #37, #39) by removing the _AnyHashableProtocol hack from initial implementation of SE-0131.

Nate Cook made substantial revisions and extensions to the documentation for integer types & protocols.

Philippe Hausler submitted a pull request that dramatically improves String bridging performance for certain cases.

When Swift strings are bridged back into Objective-C two distinct methods can be called to get fast-access to the underlying buffers of the strings. These come in two flavors - either eight-bit contents or unicode contents. When the backing of the swift string is represented as a buffer of unicode characters (an element width of 2) the fastest and smallest encoding is unicode (NSUnicodeStringEncoding = 10) and the buffer can be portrayed to Objective-C directly as a cast of the startUTF16 to a constant unichar pointer. Likewise when the backing is ASCII the buffer can be represented as an eight bit encoding (NSASCIIStringEncoding = 1) and the buffer can be directly accessed as a constant char pointer.

This in normal cases can improve the bridging performance in the upwards of 90% faster access in bridged cases when passing a swift string into Objective-C APIs.

Enrico Granata merged changes to allow demangling of methods in extensions.

Alex Blewitt added supported for ISO8601 calendars in swift-corelibs-foundation.

Accepted proposals

Proposal SE-0141: Availability by Swift version was accepted.

Feedback on the proposal was light but entirely positive. The proposal is accepted.

This proposal allows to you make declarations conditionally available, depending on the version of Swift. For example, you can currently declare a class as being available only in iOS 10 and later with @available(iOS 10.0, *). After this proposal, you could write @available(swift, introduced: 3.1) to specify that an API is only available in Swift 3.1 or later.

Proposal SE-0142: Permit where clauses to constrain associated types was accepted.

Feedback on this proposal was overwhelmingly positive. The proposal is accepted.

This proposal introduces where clauses for associatedtype declarations, bringing the same expressiveness as generic type parameters.

Mailing lists

Ben Asher asked for advice on debugging slow compile times and shared some stats on his project. Mark Lacey replied with a few tips.

Since upgrading to Swift 3, the number of trouble function bodies has gone from > 150 to < 20, so we’re really happy about that! The only issue though is that build time overall increased by ~1 min (amount of time to build all targets before automatically merging to master in our integration build).

Erica Sadun noted some unintended consequences from implementing SE-0111.

SE-0111 established that Swift’s type system would not allow function argument labels to be expressed as part of a function type. As I’ve been working with curried functions, I’m discovering an unintended consequence of this proposal in that it strips curried functions of their external labels and the resulting calls of their readability.

Finally

Is Apple using Swift in iOS, yet? It looks like the iOS 10 Music app is mostly Swift! 😎 But it looks like not much else, unfortunately.