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.

Starter tasks

  • SR-5832: Eliminate curried function representation from ASTs
  • SR-5819: Suggest as? AnyHashable when as? Equatable or as? Hashable is 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 subscript could refer to subscript declaration

Submit a task by sending a pull request or opening an issue.

Swift Unwrapped

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

LLVM 5.0.0 version is complete and marked as final. In a few days it will be published on LLVM’s web-page.

Greg Heo published an article called “The Strange Case Of Mapping Over Optionals” at Swift Unboxed. Greg describes the differences in using map and flatMap with optionals and collections, and explains what types are returned after applying map or flatMap and why.

Vincent Benony wrote an article on the Hopper Disassembler blog about injecting methods in Swift at runtime. If you really need this, this article might help you.

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

Greg Spiers pushed draft proposal about Ownership on protocol property requirements and provided a draft implementation.

Xi Ge implemented a refactoring action to simplify long number literal format. (SR-5746)

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.

Joe Groff opened a work-in-progress pull request to support key path subscripts.

Slava Pestov opened a pull request to fix confusing redundant constraints for generated interfaces of the form protocol P : AnyObject.

Kyle Murray implemented an improvement for proposals status page. Since all proposals are now required to have an implementation, the status page should show a link to those implementations.

Proposal updates

Robert Widmann is working on an implementation of SE-0155 Normalize Enum Case Representation.

SE-0075 Adding a Build Configuration Import Test is implemented in Swift 4.1.

SE-0183 Substring performance affordances is implemented in Swift 4.0.

SE-0104 Protocol-oriented integers is implemented in Swift 4.0.

Proposals in review

SE-0184: Unsafe[Mutable][Raw][Buffer]Pointer: add missing methods, adjust existing labels for clarity, and remove deallocation size by Kelvin Ma is under 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.

Mailing lists

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 […]

Peter Steinberger‏ discovered an older thread about the problems of implicit conversion in an email from John McCall, “RFC: bridging peephole for as casts”:

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:

  1. 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”.

  2. 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.

  3. 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.

[…]

Finally

And finally — for your next whiteboarding interview. 😂