The last two weeks have passed very quickly. I volunteered to help my country plan and develop a system for distributing Covid-19 vaccines to those most in need. I hope everything runs as smoothly as it can.

I want to say thank you to the people and companies that have reached out about sponsorship. Thank you for that! It makes a big difference, and we still have free spots to support this newsletter and help us cover the running costs.

Lately, we have seen a rapid increase in new proposals from the community. It’s been great to see new folks joining and expressing their ideas. That means there’ll be more for us to cover, so let’s get on with the news.

Starter tasks

• SR-14058 Trying to coerce regular function to @convention(c) traps

Podcasts

In Empower Apps #77, Leo Dion talks with Sven A. Schmidt, co-creator of the Swift Package Index. They discuss the challenges of supporting thousands of Swift Packages, dealing with metrics and site ops with Vapor, running CI for the site and the plethora of Swift packages as well as Apple Silicon support.

News and community

Soroush Khanlou wrote a blog post about launching Meridian - a web server written in Swift that lets you write your endpoints in a declarative way.

Max Desiatov wrote an excellent article explaining structured concurrency in Swift.

Andreas Wendleder wrote a great article about rendering Disney’s Moana island scene with Swift. It’s worth reading the Hacker News thread which contains a lot of valuable insights.

Commits and pull requests

Holly Borla merged a pull request which implements heuristics for pruning the generic operator overload search space.

Meghana Gupta merged a pull request that enables ArrayBoundsCheckElimination on OSSA.

Erik Eckstein merged a pull request that fixes a crash related to single-element tuples containing a label and a closure.

Evan Wilde merged a pull request that adds async-main support.

Accepted proposals

SE-0298: Async/Await: Sequences was accepted with modifications.

Feedback was overwhelmingly positive, with most of the discussion (and concerns) focused on the cancel() requirement of AsyncSequence. In light of this feedback, the proposal authors have determined at cancel() should be removed. The Core Team has accepted this proposal with the following modifications:

• The cancel() requirement has been removed from AsyncSequence, per discussion feedback.
• The first() method has been removed. It’s non-asynchronous counterpart is a property, but at present properties cannot be async. With async properties under active discussion, the Core Team felt that it would be better to let that discussion settle first (which may result in first becoming an async property) than risk having to change this declaration from a method to a function soon.
• The makeAsyncIterator has been marked as __consuming. This is mostly an implementation detail, but is in line with Sequence.makeIterator.

Proposals in review

SE-0300: Continuations for interfacing async tasks with synchronous code is under a review.

Asynchronous Swift code needs to be able to work with existing synchronous code that uses techniques such as completion callbacks and delegate methods to respond to events. Asynchronous tasks can suspend themselves on continuations which synchronous code can then capture and invoke to resume the task in response to an event.

SE-0299: Extending Static Member Lookup in Generic Contexts is under a review.

Using static member declarations to provide semantic names for commonly used values which can then be accessed via leading dot syntax is an important tool in API design, reducing type repetition and improving call-site legibility. Currently, when a parameter is generic, there is no effective way to take advantage of this syntax. This proposal aims to relax restrictions on accessing static members on protocols to afford the same call-site legibility to generic APIs.

SE-0295: Codable synthesis for enums with associated values is under the second review.

Codable was introduced in SE-0166 with support for synthesizing Encodable and Decodable conformance for class and struct types, that only contain values that also conform to the respective protocols.

This proposal will extend the support for auto-synthesis of these conformances to enums with associated values.

SE-0293: Extend Property Wrappers to Function and Closure Parameters is under the second review.

Property Wrappers were introduced in Swift 5.1, and have since become a popular mechanism for abstracting away common accessor patterns for properties. Currently, applying a property wrapper is solely permitted on local variables and type properties. However, with increasing adoption, demand for extending where property wrappers can be applied has emerged. This proposal aims to extend property wrappers to function and closure parameters.

Swift Forums

Holly Borla updated the SE-0293: Extend Property Wrappers to Function and Closure Parameters pitch.

• Passing a projected value using the $ calling syntax is supported via init(projectedValue:).
• The type of the unapplied function reference uses the wrapped-value type by default. Referencing the function using the projected-value type is supported by writing $ in front of the argument label, or $_ if there is no argument label.
• Closures with property-wrapper parameters have the same semantics as unapplied function references.
• Additional arguments in the wrapper attribute are supported, and these arguments have the same evaluation semantics as default function arguments.

Yim Lee purposed an idea to add signed package collections.

Since Package Collections (SE-0291) can be created and published by anyone, issues related to authenticity and integrity may emerge.

• Publishers can establish authenticity and protect their collections from tampering.
• Users can choose and consume collections based on trust guarantees and therefore help prevent package collections from being used as an attack vector.

Chris Lattner informed the community about updates to the ConcurrentValue and @concurrent closures pitch.

After a long hiatus due to the holidays and other constraints, I was able to incorporate a bunch of feedback (primarily from Doug) into the old ActorSendable proposal – largely rewriting it in the process.

Mishal Shah let folks know that an update will be performed to the swift/main branch for apple/llvm-project repository.

Cory Benfield announced a new project: Swift HTTP Structured Headers - a brand-new package that enables the Swift HTTP ecosystem to take advantage of new work being done by the IETF HTTP Working Group.

HTTP Structured Header fields are a draft specification being worked on by the IETF. They provide a set of data types and algorithms for handling HTTP header field values in a consistent way, allowing a single parser and serializer to handle a wide range of header field values. Working with HTTP header fields in the absence of Structured Header Fields often requires separate parsers and serialisers for each individual field, leading to a proliferation of parsers and serializers. Structured Header Fields address this head-on, defining a common base language for defining header fields going forward.

Doug Gregor updated the community regarding the revised actor proposal.

• Added a discussion of the tradeoffs with actor reentrancy, performance, and deadlocks, with various examples, and the addition of new attribute @reentrant(never) to disable reentrancy at the actor or function level.
• Removed global actors; they will be part of a separate document.
• Separated out the discussion of data races for reference types.
• Allow asynchronous calls to synchronous actor methods from outside the actor.
• Removed the Actor protocol; we’ll tackle customizing actors and executors in a separate proposal.
• Clarify the role and behavior of actor-independence. *Add a section to “Alternatives Considered” that discusses actor inheritance.
• Replace “actor class” with “actor”.

Kavon Farvardin shared a proposal that allows some properties to have effects specifiers (throws and async) added to them.

Nominal types such as classes, structs, and enums in Swift support computed properties, which are members of the type that invoke programmer-specified computations when getting or setting them; instead of being tied to storage like stored properties. The recently accepted proposal SE-0296 introduced asynchronous functions via async, in conjunction with await, but did not specify that computed properties can support effects like asynchrony. Furthermore, to take full advantage of async properties, the ability to specify that a property throws is also important. This document aims to partially fill in this gap by proposing a syntax and semantics for effectful read-only computed properties.

Daniel Duan pitched the idea of “bytes literals”.

I think Swift should have “bytes literals”, supported by the compiler, as well as the standard library. Both 'hello' and '\x68\x65\x6C\x6C\x6F' would be valid bytes literals, representing the same value.

What is a byte literal? They are similar to literals for strings/integers/bools. The standard library would provide similar treatment as for other literals. Specifically:

• Byte - Signless 8-bit value, not an int but has bit-twiddling facilities
• Bytes - Collection of bytes with continuous storage: random access, range replaceable, etc.
• ExpressibleByBytesLiteral, BytesLiteralType

Rintaro Ishizaki pitched a feature that expands #if functionality to postfix member expressions. Aan update-version of this proposal will be kept here and implementation here.

Swift has conditional compilation block #if ... #endif which allows code to be conditionally compiled depending on the value of one or more compilation conditions. Currently, unlike #if in C family languages, the body of each clause must surround complete statements. However, in some cases, especially in result builder contexts, demand for applying #if to partial expressions has emerged. This proposal expands #if ... #endif to be able to surround postfix member expressions.

Michael Ilseman updated us about version 2 of the FilePath APIs.

FilePath appeared in System 0.0.1 with a minimal API. This proposal adds API for syntactic operations, which are performed on the structure of the path and thus do not consult with the file system or make any system calls. These include inspecting the structure of paths, modifying paths, and accessing individual components.

Additionally, this proposal greatly expands Windows support and enables writing platform-agnostic path manipulation code.

Nate Cook pitched an idea to rename the subranges(where:) and subranges(of:) methods, approved as part of SE-0270, to indices(where:) and indices(of:).

The two methods in questions will be renamed to indices(where:) and indices(of:). In addition to solving the problem described above, this brings these methods inline with their documentation, which describes the methods as returning the indices of the matching elements.

Finally

TDD: Thirsty Driven Development