Earlier today, I finished my last working day of the year. All the holiday feelings are there now! I hope that you’ve had a great last weeks, including a great Thanksgiving for those who celebrated it!

And a big special thanks to Kristaps for helping out with this issue; I would not have been able to write it without him. 🏎

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

Starter tasks

  • SR-11884 [Compiler] Link-In ubsan_standalone If libFuzzer is used in Isolation
  • SR-11885 [Compiler] Allow operator functions to have extra arguments with default values
  • SR-11889 [Compiler] Use a Located<T> throughout the compiler instead of std::pair<SourceLoc, T>

Podcasts

In episode 82 of Swift Unwrapped, Jesse and JP talk about Swift’s New Diagnostic Architecture.

In Swift by Sundell #61, John Sundell and Tim Cordon discuss Serverside Swift.

News and community

Cory Benfield shared a security patch for SwiftNIO SSL.

Daniel Martin wrote a blog post to introduce Swift developers to C++!

Kaitlin Mahar’s talk at SwiftServer.conf is now available on video, talking about maintaining Swift libraries.

Accepted proposals

SE-0269: Increase availability of implicit self in @escaping closures when reference cycles are unlikely to occur was accepted.

This proposal has been accepted. The proposal discussion roughly divided into two parts:

  1. Discussion around hoisting the explicit mention of self into the closure capture list as the alternative to repeatedly writing explicit self in a closure body (and having the compiler fix-it encourage that style)
  2. The expansion of implicit self around the specific case where the type of self is a value type

The discussion on both topics was deeply constructive and productive. The core team wants to express their deep thanks to everyone who contributed to this discussion. Some really fantastic insights were made from different perspectives.

In the end, the core team felt that the hoisting self in the closure capture list provided a better experience where explicit self will still be encouraged as it (a) more clearly captures the intent of explicitly mentioning self and (b) syntactically will be cleaner in the cases where self is uttered multiple times.

The discussion around the expansion of implicit self was a bit more fragmented on the review, but ultimately the core team sided with expanding the use of implicit self as proposed.

SE-0271: Package Manager Resources was accepted with modifications.

The feedback was positive, but two larger issues were brought up:

  • the proposal states that resource bundles will be located next to the built executable only on Linux, but that doesn’t quite match up with how software is packaged up there. In addition, resources will also automatically be found in all locations specified here and there will be a commandline flag to add search paths to custom locations.
  • the proposal will limit the usefulness of SwiftPM commandline tools on macOS. We will make it possible to use Xcode specific resources in SwiftPM directly.

The SwiftPM code owners decided to accept a revised version of the proposal which addresses both of these issues.

Proposals in review

SE-0264: Standard Library Preview Package is under review #2.

We propose changing the Swift Evolution process to publish accepted proposals as individual SwiftPM packages, as well as a SwiftPreview package that bundles these proposal packages together. This group of packages will form the initial landing spot for certain additions to the Swift standard library.

Adding these packages serves the goal of allowing for rapid adoption of new standard library features, enabling sooner real-world feedback, and allowing for an initial period of time where that feedback can lead to source- and ABI-breaking changes if needed.

Swift Forums

Saleem Abdulrasool shared an update on reducing friction to get started with Swift through prebuilt Docker images with complete toolchains, multiple SDKs, and pre-configured VSCode!

An often cited problem for using Swift on other platforms is the effort required to get everything working together. To help address this barrier to entry, I have been exploring some options to reduce the initial friction for development on other targets (e.g. android, Linux, etc).

Now, I realize that some of my choices may be controversial for some, so, I would like to preface this as I am NOT advocating that this be the only development, merely an option for those that would like to use it. I personally prefer to develop locally and use my editor of choice, so I can completely understand why some may be frustrated with some of the tradeoffs made here. Please note that I am not trying to remove those options, merely provide an alternative which others can explore if it suits them.

Filip Sakel pitched a proposal for Better Access Control on Protocol Requirements.

The main problem is that you have to write a lot of boilerplate code. For every new requirement that you want to be inaccessible to the user for your own internal Types, you have to:

  1. Write the initial Protocol requirement (like the publish method in Publisher).
  2. Rewrite that requirement in the internal Protocol (like the _publish method in TrustedPublisher).
  3. Cancel the initial requirement with an extension implementation that throws a fatal error (like the publish method in the extension of TrustedPublisher).

What I propose is enabling the marking of Protocol requirements with Access Levels.

Brent Royal-Gordon pitched a proposal to introduce a concise version of #file.

Today, #file evaluates to a string literal containing the full path to the current source file. We propose to instead have it evaluate to a human-readable string containing the filename and module name, while preserving the existing behavior in a new #filePath expression.

David Hart pitched a proposal to add Package Manager Conditional Target Dependencies.

This proposal introduces the ability for Swift package authors to conditionalize target dependencies on platform and configuration with a similar syntax to the one introduced in SE-0238 for build settings. This gives developers more flexibility to describe complex target dependencies to support multiple platforms or different configuration environments.

Sergej Jaskiewicz pitched a proposal to add support for function calls in key paths.

Today a key path may only reference properties and subscripts:

\Array<String>.[0].count

But cannot reference method calls:

\Array<String>.[0].lowercased().count
//                 ^
//                 error: Invalid component of Swift key path

Since Swift already supports subscripts, how hard can it be to implement support for method calls in key paths? Sure, subscripts are different from regular methods, but are they different enough to be an implementation problem?

Finally

Swift 6 will include breaking changes!!!