I’ve been keeping myself busy the last two weeks with exciting things going on at work, and visiting other offices. We’ve also been hard at work on preparations for the SwiftAveiro conference, which I’m co-organizing this year.

All in all, cool stuff going on!

That said, here’s what kept some other people busy these past two weeks…

Starter tasks

• SR-12247 [Compiler] Replace the type alias ModuleDecl::ImportedModule with a dedicated struct
• SR-12248 [TypeChecker] <unknown> diagnostic location regarding Codable derived conformances

News and community

Dmitri Gribenko shared the Swift and C++ interoperability manifesto, summarized possible design options of this goal.

Nate Cook wrote a blog post on the Swift.org blog, on the newly released Standard Library Preview Package.

Slava Pestov wrote a blog post on the Swift.org blog, on Swift’s library evolution capabilities.

Will Lisac open sourced a project on top of swift-log that allows you to send logging messages to Slack.

Commits and pull requests

Max Desiatov merged a pull request, upstreaming almost a quarter of the huge patch from the SwiftWasm team, which brings us closer to enabling WebAssembly/WASI target in the compiler and running Swift code in browsers.

David Smith merged a pull request that adds the new uninitialized buffer String initializer privately, improving its performance.

Pavel Yaskevich merged a pull request mostly finishing the diagnostics engine rewrite, and the people working on the expression checker are now ready to rip out the old implementation completely!

Doug Gregor merged a pull request to add support for patterns in “if” statements for function builders, so one can use if-let, if-case, etcetera.

Accepted proposals

SE-0277: Float16 was accepted.

The review has concluded and the proposal is accepted.

SE-0274: Concise magic file names was accepted.

The second review has concluded and the proposal has been accepted.

• #file will be altered to only report the module and filename
• #filePath will be introduced to replicate the previous full file+path for use cases that relied on the path previously.
• While the team acknowledges that this does require some existing workflows to adapt to the new scheme, the binary size and privacy concerns over implicitly embedding the full path were significant enough to warrant this change.

During the second review, the format of the new #file value was discussed and will be locked down in a way that users can rely on. The core team expects future tooling to be created that will allow for easy processing of this value.

Proposals in review

SE-0278: Package Manager Localized Resources is under review.

This proposal builds on top of the Package Manager Resources proposal to allow defining localized versions of resources in the SwiftPM manifest and have them automatically accessible at runtime using the same APIs.

The recently accepted Package Manager Resources proposal allows SwiftPM users to define resources (images, data file, etc…) in their manifests and have them packaged inside a bundle to be accessible at runtime using the Foundation Bundle APIs. Bundles support storing different versions of resources for different localizations and can retrieve the version which makes most sense depending on the runtime environment, but SwiftPM currently offers no way to define those localized variants.

While it is technically possible to benefit from localization today by setting up a resource directory structure that the Bundle API expects and specifying it with a .copy rule in the manifest (to have SwiftPM retain the structure), this comes at a cost: it bypasses any platform-custom processing that comes with .process, and doesn’t allow SwiftPM to provide diagnostics when localized resources are mis-configured.

Without a way to define localized resources, package authors are missing out on powerful Foundation APIs to have their applications, libraries and tools adapt to different regions and languages.

Swift Forums

Saleem Abdulrasool shared that Foundation’s full test suite passes on Windows!

I am extremely excited to announce that as of today we have the full test suite for Foundation passing on Windows as well! Although there are a few tests which are testing Unix specific behaviors which do not port, this is largely on parity with the Linux test suite. There are a total of 1706 tests on Windows that are running with Linux currently having 1714.

Yuta Saito shared an update on the progress of the WebAssembly compiler target.

Now that the swiftwasm project succeeds to pass quite a few tests in its test suite, we are planning to send some patches to upstream.

Before sending them, I want to confirm and clarify the direction of supporting WebAssembly.

Sergej Jaskiewicz shared an idea to add support for Rust targets to the Swift Package Manager.

I’ve just come up with this crazy idea: what if we allow SPM to build Rust targets?

For now I have the following in mind:

• Obviously, for building Rust targets the rust toolchain has to be installed.
• We don’t use Cargo for building Rust targets, but rather invoke rustc directly. We could allow Swift packages to depend on Cargo packages in the future, but that seems nontrivial.
• Rust targets can only depend on other Rust targets. Swift or Clang targets cannot depend on Rust targets. Why? Because it would require a lot of work. Later we could allow Rust targets to have the “include” directory just like Clang targets, which would contain C headers for that target so that the Rust target could be used from Swift using those headers (just like C++ targets today can be used from Swift via C headers).

Gwynne Raskind pitched a proposal to add property wrapper requirements in protocols.

It is sometimes desirable for a protocol to require that a conforming type use a property wrapper in the declaration of a required property. This allows consumers of the protocol to access the wrapper’s projected value and properties, not just the wrapped value.

We propose allowing a subset of property wrapper syntax to appear in protocol declarations.

Joe Groff shared an update on SE-0110 and SE-0155.

In the Swift 3 era, several source-breaking proposals had been accepted with the goal of cleaning up and regularizing parts of the language. However, many of them have been stuck in the “Accepted” but not “Implemented” stage for quite a while now, because we never quite got , and the barrier for breaking source compatibility is much higher now than it was in the heady early days of Swift evolution. As such, the Core Team has started going through some of these proposals to record their current implementation status and subset out remaining unimplemented source-breaking changes. To start off, I recently reviewed the implementation status of two proposals:

• SE-0110, Distinguish between single-tuple and multiple-argument function types
• SE-0155, Normalize Enum Case Representation

SE-0110

This proposal changed the behavior of functions with multiple arguments from being considered to have one formal argument of tuple type to instead be treated as formally having multiple arguments. This change has been fully implemented as of Swift 5.2; however, the original proposal as reviewed did not include the special-case conversion from (T, U, ...) -> V to ((T, U, ...)) -> V for function arguments. In response to community feedback, this conversion was added as part of the Core Team’s acceptance of the proposal. If and when that happens, it will be done as a fresh pitch and proposal.

SE-0155

Although unfortunate, the Core Team does not consider it worth breaking source compatibility to change this behavior. Therefore, the pattern matching part of the proposal has been downscoped to allow for disambiguation when multiple cases share a base name, without changing the behavior for existing enums supported today.

Reda Lemeden asked a question about Swift Package naming conventions.

• Some packages use dash-case (aka kebab-case). Notable examples: swift-driver, swift-numerics, swift-log, swift-crypto, and swift-nio. Other that fall into this group are SSWG packages and the new standard library preview packages.
• Some packages use CamelCase. Notable examples: SwiftPM itself, SourceKitLSP, and SwiftSyntax. Almost all iOS/macOS packages follow this convention.

I understand if this detail is considered trivial or irrelevant, especially since package names play a much lesser role compared to other package managers such as npm. It is also worth noting that this situation is not unique to SPM and can be found in other ecosystems, such as Rust, where snake_cased and dash-cased crate names are both widely used (although the latter is gaining more momentum).

At the same time, I think that with the eventual introduction of a package registry (GitHub’s or otherwise), these naming inconsistencies are going to surface to the end user much more than they do today.

Is the absence of SPM package naming guidelines by design? If so, can someone shed some light on this? If it is not, would it make sense to pursue converging towards one convention? Could it happen organically or should it be enforced on the manifest level?

Finally

// FIXME, oops I mean // FORGIVE ME