Issue #104 08 Mar 2018
Written by: Bas Broek
A lot has happened in the past two weeks. Apple introduced a new open source framework, a new Xcode beta was released (with improved compile-times!) and Swift 4.2 was announced. And of course, Swift 5 has seen another two weeks of progress.
So, without further ado…
- SR-6979 [Compiler]
thin_to_thick_functionderived pointers do not need to be retained/released
- SR-6960 [Standard Library] Floating-point
nextDownare unnecessarily slow for concrete types
- SR-6889 [Compiler] Use
ArgMemOnlyfor runtime functions
- SR-6789 [Foundation]
In episode 48, Jesse and JP discuss the Google Summer Of Code 2018 and Swift’s participation in the project. In episode 49, they discuss Dave DeLong’s Swift Protocol Wishlist, looking at the possibilities of Swift Protocols without boundaries.
News and community
Ted Kremenek announced Swift 4.2 and its planned release process. Swift 4.2 “is meant to be a waypoint towards achieving ABI stability in Swift 5 [..] as well as have a goal of some focused improvements on compile-time performance”. 🎉
Jordan Rose wrote a blog post exploring types with multiple
Ben Asher shared their clean build times (with the “old” build system) decreased by 4 minutes compared to Xcode 9.2; from 11 minutes to 7 minutes, that’s a 36% speedup!
Alfredo Delli Bovi shared similar results, going from 7 and a half minutes to 5. 🏎
At try! Swift, Norman Maurer introduced SwiftNIO, “a cross-platform asynchronous event-driven network application framework for rapid development of maintainable high performance protocol servers & clients”. Interesting to note is that they are using GitHub Issues; no JIRA!
Vapor then integrated with SwiftNIO mere days after the announcement. They were able to delete nearly 15.000 lines of code! 😮
Marcin Krzyżanowski wrote how they created a first-class Swift API for an Objective-C framework, using all the amazing bridging and attributes available.
Commits and pull requests
This PR intends to improve matters by standardizing on a high quality hash function, SipHash, for use inside the standard library and inside compiler-synthesized
Hashableimplementations. (SipHash is already implemented in the Standard Library, but so far it has been sitting there largely unused.)
This pull request does not introduce a public API to help with manual
Hashableimplementations — but it provides the first step towards providing one.
The new API for customizing playground display will be adopted, and the previous API deprecated, as described in the proposal. However, the new protocol will remain part of the standard library rather than moving to the playground support library, in order to facilitate frameworks that want to ship with built-in custom playground display capability.
The review of SE-199 has ended, and the proposal has been accepted as-is. There was some discussion during the review of alternative names, but the team felt that
toggle()was the best one offered.
Over the last few weeks I’ve been discussing this with the core team, who pretty much all agreed that this is not the right direction for third-party libraries.
I’m working on cutting down the proposal text (and the implementation) to match this feedback from the core team.