Issue #63 30 Mar 2017
Written by: Jesse Squires
The big news this week was that Swift 3.1 was officially released! Congratulations to the Core Team and open source contributors! This was a huge effort and aside from the notable features and proposals, there were dozens of bug fixes and other improvements. Be sure to report any bugs, regressions, or other issues that you run into.
In this five-episode tutorial series, Marin Todorov guides us on a sample app project in Swift to see how Realm facilitates building reactive Swift apps from the ground up.
Episode 4: Bridging with Objective-C
This week we discuss bridging! There’s been a constant push and pull on Objective-C bridging since Swift 1.x, trying to seek a balance but always swaying in the other direction.
News and community
Swift 3.1 was officially released!
Swift 3.1 is a minor release that contains improvements and refinements to the Standard Library. Thanks to efforts by IBM and other members of the community, it also includes many updates to the Linux implementation of Swift. There are also a number of updates to Swift Package Manager.
Swift 3.1 includes the following proposals:
- SE-0045: Add prefix(while:) and drop(while:) to stdlib
- SE-0141: Availability by Swift version
- SE-0080: Failable Numeric Conversion Initializers
- SE-0147: Move UnsafeMutablePointer.initialize(from:) to UnsafeMutableBufferPointer
- SE-0082: Package Manager Editable Packages
- SE-0145: Package Manager Version Pinning
- SE-0152: Package Manager Tools Version
- SE-0151: Package Manager Swift Language Compatibility Version
Xcode 8.3 was released along with updates to all of Apple’s platforms. Xcode 8.3 ships with Swift 3.1.
Bas Broek wrote a post on the cost of Swift evolution, highlighting this Twitter thread with Austin Zheng and Slava Pestov. This is something I’ve discussed before as well. It’s important to recognize that there is a huge opportunity cost to swift-evolution, that is, the cost of each change are those changes we give up in return. This is especially true regarding features/proposals that don’t align with Swift’s roadmap, or theme. As Slava points out, the Core Team needs (and deserves!) time to focus on bug fixes, performance improvements, and addressing technical debt. Personally, I wouldn’t mind seeing fewer proposals, or as Bas suggests, a temporary halt on swift-evolution. Having said that, I think the team has so far managed Swift 4 much better than Swift 3, which included a ton of proposals.
Commits and pull requests
Hugh Bellamy (@hughbe) has continued working hard to get Swift working on Windows and submitting a number pull requests to swift, swift-llvm, swift-lldb, and other repos for weeks (maybe months?) now. This week, he has a grim update to get the
update-checkout script working on Windows.
Slava Pestov (@slava_pestov) merged SILGen fixes for static
Self-returning methods. This is a crazy fix that I don’t completely understand. 😅 The first line of the commit says it all, “Take a seat and pour yourself a beer because this is going to get pretty intense.”
There’s still been heavy debate on the lists over SE-0159: Fix Private Access Levels. The core arguments that I covered last week haven’t changed so I’ll avoid belaboring them. The review period was supposed to end on March 27, so we should see a decision from the Core Team soon. My impression is that these discussion sort of burnt out the community as the lists have been relatively quiet since. 😄
This proposal is to implement a subset of the changes from the Swift 4 String Manifesto.
- Create a
- Create a
Unicodeprotocol to allow for generic operations over both types.
- Consolidate on a concise set of C interop methods.
- Revise the transcoding infrastructure.
Other existing aspects of
Stringremain unchanged for the purposes of this proposal.
And finally — static typing.