Welcome to issue 85! This week was quieter than last, but various discussions on concurrency continued. Proposal SE-0184: Improved pointers was updated and is waiting to get merged back into the swift-evolution repository.

Interested in sponsoring Swift Weekly Brief? Learn more here.

Swift Unwrapped

In Episode 26: Swift 5 Goals, Jesse and JP share their thoughts on the newly announced goals for Swift 5.

News and community

A discussion came up regarding problems with diagnostics and the “tuple-splat” changes in Swift 4. There’s definitely a lot of frustration in the community here. Swift certainly has room to improve on diagnostics and error messages to make migrating from Swift 3 to Swift 4 smoother.

Brian Gesiak generated a graph of the Swift compiler executable and its dependencies. 🤓

Commits and pull requests

Robert Widmann opened a pull request with an implementation for SE-0075, which was originally accepted for Swift 3. 😅

Slava Pestov fixed an issue where calling a protocol extension initializer from a class convenience initializer would incorrectly use the static Self type rather than the dynamic type. Note that this is a source-breaking change for Swift 5. Also, it appears corelibs-foundation was relying on that bug, so he proposed a fix there as well.

Currently the mangled names for subscripts include “subscript”, for example _T04main3FooC9subscriptAA6OutputVAA5InputVci. Alex Hoppen opened a pull request request to fix this, which makes subscript mangled names more consistent with others. (SR-5506)

Jordan Rose merged two pull requests: Excise “Accessibility” from the compiler and Update for Swift renames of “Accessibility” to “Access(Level)”. It’s a cosmetic change, but 100% justified. This definitely makes the code more readable and easier to understand from an app developer perspective.

“Accessibility” has a different meaning for app developers, so we’ve already deliberately excised it from our diagnostics in favor of terms like “access control” and “access level”.

Erik Eckstein fixed an issue which can crash the compiler when a global struct or tuple has one or more elements as an empty type (e.g. an empty tuple or empty struct).

Erik Eckstein also merged optimizations that give significant performance improvements for large array literals.

Kelvin Ma opened a pull request with updated version of SE-0184: Improved pointers.

John Holdsworth opened a pull request to get XCTest building on Android.

Proposals

No updates this week! See the status page here.

Mailing lists

Adam Kemp started a discussion on the scope of the await keyword to clarify how exactly await is applied in case there are several functions calls in one line. From Chris Lattner:

Yes, this is a reasonable concern. We debated it heavily in the Swift 2 timeframe when introducing error handling (as other’s have pointed out, it works the same way).

This is a tradeoff between the readability benefits of marking non-obvious control flow vs the readability disadvantage of having noise in the code. Requiring marking on every async or throwing call is particularly bad in the case of chaining.

[….]

In the Swift 2 timeframe, we decided that in many cases, it is mostly obvious what APIs can throw, so one marker is enough. That said, there ARE potentially confusing cases, and some programmers may want to be more explicit about marking. This is why the compiler allows you to explicitly mark subexpressions if you’d like.

I believe that this design has served the community well, and I haven’t heard of serious problems with it. I’m pretty confident that async following the same model will have similar success.

Howard Lovatt discussed reactive streams as building blocks for actors.

Many of the currently popular server side frameworks are switching to Reactive Streams for their underlying communication, including Akka. Reactive Streams are also to become builtin to Java, as the Flow class, in version 9.

Would it be wise if Swift 5 also builtin Reactive Stream protocols and built its Actor implementation etc. on top of this protocol?

Chris Lattner added this in a new “Further extensions” section of the Concurrency Manifesto. So maybe we’ll get this some day!

Logan Shire pitched an idea for improvements to KeyPath.

Firstly, KeyPath does not provide the name of the property on the type it indexes. […] But once I have a keyPath, I can’t actually figure out what property it accesses.

[…]

All I want is to be able to access: keyPath.propertyName […]

Also, if I want to get all of the attributes from a given Swift type, my options are to try to hack something together with Mirrors, or forcing the type to declare a function / computed property returning an array of all of its key path / property name pairings. I would really like to be able to retrieve a type-erased array of any type’s key paths…

And finally, without straying too far into Objective-C land, it would be nice if we could initialize key paths with a throwing initializer…

Joe Groff was supportive:

These would all be great additional features to eventually add to key paths. I think reflection mechanisms centered on key paths like what you describe would be a superior replacement for most of what Mirror attempts to provide.

Finally

And finally, me before reading swift/utils/build-script --help vs me after.