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. 🏎
Interested in sponsoring Swift Weekly Brief? Learn more here.
- SR-11884 [Compiler] Link-In
ubsan_standaloneIf 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
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
This proposal has been accepted. The proposal discussion roughly divided into two parts:
- Discussion around hoisting the explicit mention of
selfinto the closure capture list as the alternative to repeatedly writing explicit
selfin a closure body (and having the compiler fix-it encourage that style)
- The expansion of implicit
selfaround the specific case where the type of
selfis 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
selfin the closure capture list provided a better experience where explicit
selfwill still be encouraged as it (a) more clearly captures the intent of explicitly mentioning
selfand (b) syntactically will be cleaner in the cases where
selfis uttered multiple times.
The discussion around the expansion of implicit
selfwas a bit more fragmented on the review, but ultimately the core team sided with expanding the use of implicit
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
We propose changing the Swift Evolution process to publish accepted proposals as individual SwiftPM packages, as well as a
SwiftPreviewpackage 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.
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.
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:
- Write the initial Protocol requirement (like the
- Rewrite that requirement in the internal Protocol (like the
- Cancel the initial requirement with an extension implementation that throws a fatal error (like the
publishmethod in the extension of
What I propose is enabling the marking of Protocol requirements with Access Levels.
#fileevaluates 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
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.
Today a key path may only reference properties and subscripts:
But cannot reference method calls:
\Array<String>..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?
Swift 6 will include breaking changes!!!