Welcome to issue #99! 🎈 Last week we discussed the move away from the mailing lists to official Swift forums, which were intended to be fully rolled out by now. Unfortunately, the rollout has been delayed until early next year due to feedback from users and the holiday season. Almost there! In other news, two exciting proposals were introduced this week that have significant implications for library authors, the Swift ABI, and potential performance improvements. Swift 5 is starting to look like a very exciting release!

有兴趣赞助 Swift Weekly Brief？点击这里

Swift Unwrapped

Episode 40: Dynamic Member Lookup Proposal. JP and Jesse discuss Chris Lattner’s recent “Dynamic Member Lookup” proposal.

News and community

The new Discourse-based Swift forums are online, but not 100% functional yet. The full rollout has been rescheduled for early next year. However, you can sign-up with GitHub and start testing out the prototype to give feedback to the team! Nicole Jacque writes:

First of all, a big thank you to everyone who has provided feedback on our prototype Discourse forum. Based on the fact that we’re still receiving feedback, we’d like to move to a slightly less aggressive schedule for our rollout, in order to make sure that we’ve adequately addressed it. We’re still working out an exact schedule, but due to the upcoming holidays, I expect that we’ll be looking at shortly after the beginning of the new year.

In the meantime, I’ve moved the prototype forum to forums.swift.org, and I have GitHub-enabled logins working if you’d like to give it a try! You can also test out registering (including using the staged account pre-created from your mailing list account). Instructions are here.

Once you’ve created an account, you’ll be able to experiment with the various account and notification settings that are available to you.

If you have feedback or see any issues, (especially with login) please file issues/comments/requests at bugs.swift.org under the “Project Infrastructure” component for tracking.

Mike Ash wrote a great Friday Q&A on Type Erasure in Swift. Back when I was first introduced to type erasure, it was difficult to understand. If that’s how you feel now, give this article a read. I think Mike provides some great examples.

objc.io published a blog post, on String performance with a pretty clever tip.

The reason for the performance gain: a string can be backed by a Swift String or an NSString. By appending an empty string, we force it to be backed by a Swift String, with which our algorithm works much faster.

Ole Begemann wrote a post on importing a C library in Swift using SPM. It’s an excerpt from their book, Advanced Swift, which I’d also highly recommend!

Nikolay Igotti announced reverse interop from Objective-C and Swift for Kotlin. You can now call Kotlin code from Swift and Objective-C.

Brian Gesiak continued his series on the Swift compiler with Option Parsing in the Swift Compiler.

Commits and pull requests

I didn’t have enough time this week to browse through commits and pull requests, but know that the Swift team as been as busy as ever! This time of year we usually see refactorings, optimizations, and generally a lot of technical debt being paid off, which is great!

Accepted proposals

SE-0187: Introduce Sequence.compactMap(_:) was accepted.

Hi, Swift community! I apologize for the delay in reporting our decision here; between one holiday and the other, it took awhile for the core team to assemble a quorum to talk through this. […] The result of the first review was consensus to rename the method, and the purpose of the second review was to get more specific feedback on what the new name should be.

“filterMap” is a name with some precedent in other programming languages, especially functional ones, but some people felt strongly that the name was misleading because, as a combined operation, it wasn’t quite a filter or a map. Of the alternatives, the one with the strongest support seemed to be “compactMap”, which builds on the precedent of “compact”, an operation from other languages (notably Ruby) which returns a copy of the input without nil values. Swift does not currently have such an operation, and in fact it is not currently possible to express it; nonetheless, the core team agrees that it would be a reasonable operation to add, and that “compactMap” is a good name for the operation.

Therefore, SE-0187 is accepted, with the revision that the new name be Sequence.compactMap(_:), and with the agreement that we will add Sequence.compact() when it is possible to do so.

Thank you all for your continued contributions to making Swift a better language.

Proposals in review

SE-0192: Non-Exhaustive Enums by Jordan Rose is under review.

Currently, adding a new case to an enum is a source-breaking change, which is very inconvenient for library authors. This proposal aims to distinguish between enums that are exhaustive (meaning they will never get any new cases) and those that are non-exhaustive, and to ensure that clients handle any future cases when dealing with the latter. Some key notes:

  • This only affects public enums.
  • With rare exceptions, this does not affect switch statements in the same target as the enum.

This is definitely an exciting proposal for library authors! In Swift 5, public enums can be declared as @exhaustive, otherwise they default to non-exhaustive. The design and effects of such a seemingly small change are really interesting. I’d recommend reading the full proposal. It’s also important to note that this proposal effects ABI stability:

Currently, the layout of a public enum is known at compile time in both the defining library and in its clients. For a library concerned about binary compatibility, the layout of a non-exhaustive enum must not be exposed to clients, since the library may choose to add a new case that does not fit in that layout in its next release.

SE-0193: Cross-module inlining and specialization by Slava Pestov is under review.

We propose introducing a pair of new attributes, @inlinable and @abiPublic. The @inlinable attribute exports the body of a function as part of a module’s interface, making it available to the optimizer when referenced from other modules. The @abiPublic attribute marks an internal declaration as being part of the binary interface of a module, allowing it to be used from @inlinable code without exposing it as part of the module’s source interface.

One of the top priorities of the Swift 5 release is a design and implementation of the Swift ABI. This effort consists of three major tasks:

  • Finalizing the low-level function calling convention, layout of data types, and various runtime data structures. […]

  • Implementing support for library evolution, or the ability to make certain source-compatible changes, without breaking binary compatibility. […]

  • Stabilizing the API of the standard library. The goal here is to ensure that the standard library can be deployed separately from client binaries and frameworks, without forcing recompilation of existing code.

All existing language features of Swift were designed with these goals in mind. In particular, the implementation of generic types and functions relies on runtime reified types to allow separate compilation and type checking of generic code.

[…]

On the other hand, across module boundaries, runtime generics introduce unavoidable overhead, as reified type metadata must be passed between functions, and various indirect access patterns must be used to manipulate values of generic type. We believe that for most applications, this overhead is negligible compared to the actual work performed by the code itself.

However, for some advanced use cases, and in particular for the standard library, the overhead of runtime generics can dominate any useful work performed by the library. Examples include the various algorithms defined in protocol extensions of Sequence and Collection, for instance the map method of the Sequence protocol. Here the algorithm is very simple and spends most of its time manipulating generic values and calling to a user-supplied closure; specialization and inlining can completely eliminate the algorithm of the higher-order function call and generate equivalent code to a hand-written loop manipulating concrete types.

[…]

Another exciting proposal for library authors and Swift in general. This proposal has significant implications for potential performance improvements. I have high hopes for Swift 5. 😄 🤓

Finally

And finally — great hires for functional programming roles. 😄