Issue #41 06 Oct 2016
Written by: Jesse Squires
Welcome to issue 41! Swift 4.0 development continues, and it looks like Swift 3.0.1 Preview-2 has landed.
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
unicharpointer. 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
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.
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.
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.
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).
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.