Not only did the Swift repository pass 18,000 pull requests (after the internal repository had 18,000 SVN revisions after four years), it also celebrated its 8th birthday! Impressive numbers, and may many more follow.

Apart from that, I hope many of you are enjoying an awesome summer!

Starter tasks

• SR-8252 [Compiler] Consolidate and Fix -debug-crash-* Flags
• SR-8253 [Compiler] catch clause should allow multiple patterns
• SR-8327 [Package Manager] Improve error message when bootstrapping SwiftPM without cmake or ninja

Swift Unwrapped

Jesse and JP are taking a well deserved summer break. ☀️🏖

News and community

Cory Benfield announced the release of NIOTransportServices to help users use Network.framework with a SwiftNIO API.

Commits and pull requests

Slava Pestov merged a pull request that continues the work of SE-0002 (!), removing multiple parameter lists from the Abstract Syntax Tree (AST).

Ben Cohen merged a pull request that refactors some code making use of conditional conformances. The result? +276, -2,694 lines of code. Impressive!

Doug Gregor merged a pull request involving protocol metadata. This is also part of ABI stability and improving reflection. According to Slava, “This all lays the groundwork for powerful metaprogramming capabilities that go far beyond the standard library’s Mirror type”. 🎉

Accepted proposals

SE-0215: Conform Never to Equatable and Hashable was accepted.

The Core Team discussed the review, and reached the following conclusions:

• The proposal should be accepted with the new explicit conformances to Equatable and Hashable be added to Never. This addresses a real point of friction users are experiencing with the use of Never.

• For the same reasons conformances to Hashable and Equatable are being added to Never, the Core Team felt that conformances to Error and Comparable should also be added to Never as part of accepting this proposal. Both of these additional protocol conformances were brought up during the review.

• Never should become a blessed bottom type in the language. This matches with semantics in other languages and its intended role in Swift.

With respect to the latter, the Core Team discussed what Never being a bottom type actually meant. From that discussion we reached the following conclusions:

• Semantically, as a bottom type, it would mean that Never should be implicitly convertible to any other type. This composes well in the type system because of the fact that instances of Never cannot be instantiated.

However, being a bottom type does not imply that Never should implicitly conform to all protocols. Instead, convenient protocol conformances for Never should be added as deemed useful or necessary.

SE-0218: Introduce compactMapValues to Dictionary was accepted.

Feedback on the proposal was very positive – the main concern being with the name, but this falls naturally out of our existing method names so is consistent, if clunky.

SE-0219: Package Manager Dependency Mirroring was accepted with revisions.

The review of SE-0219 “Package Manager Dependency Mirroring” ran from July 10…17. Feedback was positive, and the proposal is accepted with revisions (adding a swift package config get-mirror command). Thanks to everyone who participated!

Rejected proposals

SE-0217: Introducing the !! “Unwrap or Die” operator to the Swift Standard Library was rejected.

The core team has decided to reject this proposal as written. However, the core team concurs that the motivating problems posed by the proposal are important to solve, as did an overwhelming majority of commenters who participated in the public review. The fact that the only fixit the compiler offers to unwrap an Optional is to use the ! operator is an unfortunate legacy of the Swift 1.0 days, before anything in the SDKs Swift was designed to work with had been audited for nullability, so force-unwrapping was far more of a necessity. Nowadays this legacy is actively harmful, and encourages bad habits in new Swift programmers, as the proposal and review discussion highlight extensively. It is clear too that ! giving inadequate runtime feedback is a major problem, since a large contingent of the Swift community follows style guides that flat-out ban it, and the guard ... else { fatalError("message") } idiom is widespread as a way of more thoughtfully crashing on nil with an actionable error message.

I’d encourage you to read the rest of the rationale.

Proposals in review

SE-0221: Character Properties is under review.

Tony Allevato (a co-author here) proposed Add Unicode Properties to Unicode.Scalar, which exposes Unicode properties from the Unicode Character Database. These are Unicode expert/enthusiast oriented properties that give a finer granularity of control and answer highly-technical and specific Unicody enquiries.

However, they are not ergonomic and Swift makes no attempt to clarify their interpretation or usage: meaning and proper interpretation is directly tied to the Unicode Standard and the version of Unicode available at run time. There’s some low-hanging ergo-fruit ripe for picking by exposing properties directly on Character.

Swift Forums

Ankit Aggarwal shared news about some recently added features in SwiftPM, namely the caching of manifests.

[..] SwiftPM will now cache the loaded manifests for effectively all operations except dependency resolution. This provides great performance improvements during iterative development. Commands like swift build, swift test, swift package edit, swift package generate-xcodeproj should start significantly faster once the cache is created. For e.g., time spent to load all manifests of Vapor reduces from 3.7s to 64ms!

Jordan Rose shared an update on module stability, which he will be working on in “the next year or so”.

ABI stability means that an executable compiled against Swift 5 will work with the Swift 6 libraries, and that an executable compiled against Swift 6 will work with the Swift 5 libraries. A related concept is module stability, which says that the interface for a Swift 5 library will work with the Swift 6 compiler. (The opposite direction is less interesting.) More generally, the interface for a library should be forward-compatible with future versions of the compiler. This is useful in a number of ways:

• Can test a new compiler without rebuilding all of an app’s dependencies.
• May overlap with work to make the debugger work across Swift versions.
• May help reduce incremental build time by better tracking cross-target dependencies.
• Support for general non-resilient binary frameworks.

If you’re interested in this, I would recommend reading the full post.

Nate Cook pitched a proposal to expose the internal array initializer that has access to an uninitialized buffer.

There is currently no way to work with a buffer of uninitialized memory that then becomes a fully memory-managed Array. This limitation means that operations that don’t know the final size of their data in advance, or that need to access noncontiguous parts of an array, are less efficient than necessary, often requiring an extra copy. This proposal suggests a new initializer for Array and ContiguousArray that would provide access to a newly created array’s entire storage buffer.

Finally

Index out of bounds. 💥