We’re very happy to announce that thanks to Zigii Wong, Swift Weekly Brief will be available in Chinese as well! You can go to the website here, and you can contribute in this repository. 🎉

In other news, there’s a potentially highly anticipated proposal in review, namely one that introduces a Result type to the Standard Library. 😱

… so go ahead and read all about this and more exciting progress on Swift.

Starter tasks

• SR-9201 [Compiler] Incorrect error message when using optional chaining
• SR-9216 [Compiler] Don’t honor SDKROOT in interpreter mode

Swift Unwrapped

Jesse and JP discussed Opaque Result Types, as pitched by Doug Gregor on the forums.

News and community

Mattt wrote a blog post about the Language Server Protocol, “arguably the most important decision Apple has made for Swift since releasing the language as open source in 2014”.

SwiftNIO is now available as a CocoaPod!

Vapor is working on splitting two new libraries out of their core library: NIOKit and CodableKit.

Commits and pull requests

David Smith merged a pull request that improves String bridging performance!

Accepted proposals

SE-0233: Make Numeric Refine a new AdditiveArithmetic Protocol was under review and then accepted.

This proposal introduces a weakening of the existing Numeric protocol named AdditiveArithmetic , which defines additive arithmetic operators and a zero, making conforming types roughly correspond to the mathematic notion of an additive group. This makes it possible for vector types to share additive arithmetic operators with scalar types, which enables generic algorithms over AdditiveArithmetic to apply to both scalars and vectors.

Feedback on the proposal was light but all positive, and the proposal was accepted without modifications. The core team discussed moving the unary + member, but ended up agreeing with the proposal as written.

Returned proposals

SE-0229: SIMD Vectors, Take 2 was returned for revision.

The proposal and implementation have been updated.

To summarize how the proposal has changed:

• The primary working types are now spelled like Vector3<T> instead of the earlier T.Vector3.
• Initializers from any Sequence with the right element type are now provided.
• All mask operations are .-prefixed
• count has been renamed elementCount
• The general swizzle / shuffle / permute operation init(gathering: at:) has been removed. We intend to restore it in a later proposal with a better name.
• Users can make VectorN<T> available for arbitrary types T by conforming T to a new SIMDVectorizable protocol, which has very basic requirements.
• The any and all and min, max, and clamp free functions have been removed. We intend to re-introduce this functionality (possibly with different bindings) in a follow-on proposal.
• The IntegerVector and FloatingPointVector protocols have been removed and replaced with conditional conformances.

Rejected proposals

SE-0231: Optional Iteration was rejected.

Although the core team agrees that iterating through collections wrapped in Optional is a common enough occurrence to be worth providing affordances in the language for, it has decided to reject the proposal as written.

I’d encourage to read the full rationale.

Proposals in review

SE-0235: Add Result to the Standard Library is under review.

Swift’s current error-handling, using throws, try, and catch, offers automatic and synchronous handling of errors through explicit syntax and runtime behavior. However, it lacks the flexibility needed to cover all error propagation and handling in the language. Result is a type commonly used for manual propagation and handling of errors in other languages and within the Swift community. Therefore this proposal seeks to add such a type to the Swift standard library.

SE-0236: Package Manager Platform Deployment Settings is under review.

This is a proposal for adding support for specifying a per-platform minimum required deployment target in the Package.swift manifest file.

Packages should be able to declare the minimum required platform deployment target version. SwiftPM currently uses a hardcoded value for the macOS deployment target. This creates friction for packages which want to use APIs that were introduced after the hardcoded deployment target version.

Swift Forums

Michael Ilseman shared String’s proposed Application Binary Interface (ABI) and that native Swift strings will be stored as UTF-8!

We just landed String’s proposed final ABI on master. This ABI includes some significant changes, the primary one being that native Swift strings are stored as UTF-8 where they were previously stored either as ASCII or UTF-16 depending on their contents. NSStrings are still lazily bridged in to String without copying.

This does not immediately surface in the API, but allows for some important performance wins and gives a more consistent basis for future APIs providing efficient and direct access to the underlying code units. UTF-8 is a one-byte Unicode encoding and is the preferred encoding for interoperating with C, systems programming, server-side programming, scripting, client-side programming, and tools that process source code and textual formats.

With this change, the Standard Library’s binary is around 13% smaller as well!

Vapor is splitting out two new libraries from its core library.

We’re starting work on two new packages that will debut with Vapor 4. NIOKit and CodableKit. The goal of these packages is to break out a lot of utilities Vapor has developed over the past two years in our Core 1 repo. This repo has grown quite large and contains a lot of things we think would be useful to the Server community as a whole, not tied to Vapor.

Johannes Weiss shared the plan for SwiftNIO 2 and how that ties into Swift 5.

As I’m sure you are aware, the first Swift 5 branches will be cut soon and needless to say SwiftNIO wants to be able to make full use of the new features/improvements upcoming in Swift 5 (for example native UTF8 Strings). On top that, SwiftNIO already accumulated a number of issues/pull requests that can only be addressed with a new major SwiftNIO 2.0.0 release.

Our plan is to therefore release SwiftNIO 2.0 together with Swift 5.0. NIO 2 will require Swift 5 and will be a breaking release. Don’t expect everything to break when you need to migrate from NIO 1 to NIO 2 but there will be likely a number of things that can hopefully be fixed mostly through search & replace. We will maintain a list of changes with strategies to resolve this.

Finally

I love this Result type!