Issue #86 07 Sep 2017
Written by: Roman Volkov
Welcome back to the weekly! The Swift project repos continue to delight with their usual activity. This week we have some new starter tasks, updates on proposals, and most excitingly, Chris Lattner’s appearance on Swift Unwrapped to talk about concurrency in Swift 5.
Interested in sponsoring Swift Weekly Brief? Learn more here.
- SR-5832: Eliminate curried function representation from ASTs
- SR-5819: Suggest
as? Hashableis attempted
- SR-5817: Swift CMake prints “Building Swift standard library and SDK overlays” and “Building Swift runtime”, even when those are not being built
- SR-5789: Fixit when failed reference to member named
subscriptcould refer to subscript declaration
In Episode 27: Concurrency with Chris Lattner, JP and Jesse welcome Chris Lattner to the show to discuss concurrency in Swift 5 and beyond.
News and community
Greg Heo published an article called “The Strange Case Of Mapping Over Optionals” at Swift Unboxed. Greg describes the differences in using
flatMap with optionals and collections, and explains what types are returned after applying
flatMap and why.
Mike Ash took a closer look at Swift’s error handling in another great Friday Q&A, exploring the similarity and differences with exceptions.
Jordan Rose wrote a great post about Over-abstraction in Swift.
Commits and pull requests
Brian Gesiak opened a pull request to link static libraries as PUBLIC in CMake, but Jordan Rose commented that not doing this was deliberate. The thread on the pull request is interesting if you’d like to learn more about CMake and the Swift intra-compiler infrastructure.
Proposals in review
Swift’s pointer types are an important interface for low-level memory manipulation, but the current API design is not very consistent, complete, or convenient.
This proposal seeks to improve the Swift pointer API by ironing out naming inconsistencies, adding sensible default argument values, adding missing methods, and reducing excessive verbosity, offering a more convenient, more sensible, and less bug-prone API. We also attempt to introduce a buffer pointer API that supports partial initialization without excessively compromising memory state safety.
Joe Groff sent an email to resume discussions about an
async coroutines implementation in Swift.
The coroutine proposal as it stands essentially exposes raw delimited continuations. While this is a flexible and expressive feature in the abstract, for the concrete purpose of representing asynchronous coroutines, it provides weak user-level guarantees about where their code might be running after being resumed from suspension, and puts a lot of pressure on APIs to be well-behaved in this respect. And if we’re building toward actors, where async actor methods should be guaranteed to run “in the actor”, I think we’ll need something more than the bare-bones delimited continuation approach to get there. I think the proposal’s desire to keep coroutines independent of a specific runtime model is a good idea, but I also think there are a couple possible modifications we could add to the design to make it easier to reason about what context things run in for any runtime model that benefits from async/await […]
So, there’s a longstanding issue that we’re planning to fix in Swift 4, and I want to both make sure that the plan is documented publicly and give people a chance to disagree with it.
A bridging conversion is a conversion between a Swift type and a foreign type (C / ObjC / whatever) which can represent the same set of values. For example, there are bridging conversions from Swift.String to ObjC’s NSString and vice-versa. When there two-way conversions like this, we say that the Swift type is bridged to the foreign type.
Bridging conversions are performed for three reasons in Swift:
You can always request a bridging conversion with an unconditional “as” cast. For example, if myString is a String, you can convert it to NSString by writing “myString as NSString”.
Certain bridging conversions can be introduced as implicit conversions. (This is perhaps a mistake.) For example, CFString and NSString are considered different types, but they will implicitly convert to each other.
Bridging conversions are done “behind the scenes” when using an imported declaration that has been given a type that does not match its original type. For example, an Objective-C method that returns an NSString will be imported as returning a String; Swift will implicitly apply a bridging conversion to the true return value in order to produce the String that the type system has promised.
And finally — for your next whiteboarding interview. 😂