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.
It’s easy to make an app by throwing some code together. But without best practices and a robust architecture, you soon end up with unmanageable spaghetti code. Learn to create solid and maintainable apps with fewer bugs with this free guide.
- SR-14058 Trying to coerce regular function to
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
Commits and pull requests
Feedback was overwhelmingly positive, with most of the discussion (and concerns) focused on the
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:
cancel()requirement has been removed from
AsyncSequence, per discussion feedback.
first()method has been removed. It’s non-asynchronous counterpart is a property, but at present properties cannot be
asyncproperties under active discussion, the Core Team felt that it would be better to let that discussion settle first (which may result in
asyncproperty) than risk having to change this declaration from a method to a function soon.
makeAsyncIteratorhas been marked as
__consuming. This is mostly an implementation detail, but is in line with
Proposals in 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.
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.
Codable was introduced in SE-0166 with support for synthesizing
structtypes, 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.
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.
- Passing a projected value using the
$calling syntax is supported via
- 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.
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.
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.
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.
- 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
Actorprotocol; 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”.
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
asyncproperties, the ability to specify that a property
throwsis also important. This document aims to partially fill in this gap by proposing a syntax and semantics for effectful read-only computed properties.
I think Swift should have “bytes literals”, supported by the compiler, as well as the standard library. Both
'\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.
Swift has conditional compilation block
#if ... #endifwhich allows code to be conditionally compiled depending on the value of one or more compilation conditions. Currently, unlike
#ifin C family languages, the body of each clause must surround complete statements. However, in some cases, especially in result builder contexts, demand for applying
#ifto partial expressions has emerged. This proposal expands
#if ... #endifto be able to surround postfix member expressions.
Michael Ilseman updated us about version 2 of the
FilePathappeared 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.
The two methods in questions will be renamed to
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.