Thank you Jeroen for covering last week’s issue. If you want to contribute or write an issue, head down to our contributions guide or let me know personally.

The slow summer trend is also continuing these past two weeks. Despite that, there are a bunch of accepted proposals and some fresh ideas on the Swift forums.

As always, I appreciate your support. Now let’s get to the news.

Starter tasks

• SR-14941 Introduce compiler warning for leading-zero octal notation
• SR-14943 [Compiler] Fix-it for changing unsafeBitcast to unsafeDowncast should be more narrow or removed
• SR-14971 [Compiler] Spurious error after wrapped ‘var’ declaration without type annotation.

News and community

Great article about using tuples in complex sorting operations in Swift.

Accepted proposals

SE-0319 Never as Identifiable was accepted.

Feedback from the review was positive, and mostly focused on further exploration of making Never a true bottom type, or similar alternatives to expanding the list of protocols Never conforms to in a systemic manner. The core team acknowledges this is an interesting design space and encourages follow up proposals exploring it.

SE-0317 Async Let was accepted.

A significant area of feedback during the review was that of the creation of implicit suspension points when an async let variable is not awaited on a path that exits a scope that is not itself an awaited function. This creates an exception to the rule that suspension points are always marked with an await.

After thorough discussion of the alternatives to implicit suspension points, the core team feels that language-level solutions add more complexity than is warranted to eliminate implicit suspension points.

The core team acknowledges that this exception may have more impact in practice than can be reasoned about without real-world use. There is an opportunity to react to real-world feedback in Swift 6 by tightening up the model around implicit awaits if it turns out that they are harmful in practice (although it is not currently the intention to do so).

The proposal authors have added descriptions of other solutions and their downsides to the alternatives considered section of the proposal. This section also has additions covering other alternatives discussed during the review, such as the use of property wrappers for a partial library-level solution.

SE-0315 Type placeholders was accepted.

Support for the added functionality was unanimous; there was some discussion about whether the proposal might be better titled “type placeholders” or “inferred types”, but that would not affect the behavior of the feature within the language. Thanks to everyone who participated in the review!

SE-0314 AsyncStream and AsyncThrowingStream second review was accepted.

The proposal is accepted. After much discussion, Core Team has decided to retain the AsyncStream and AsyncThrowingStream names as proposed.

Returned proposals

SE-0318 has been returned for revision.

The feedback from the review highlighted further refinement that can be done to the ergonomics of the proposed solution including the templating system. For example, the proposal can make it clearer why a new command is desired compared to enhancing the existing package init command, and explore a templating system that supports for multi-template-single-repo and programatic interfaces.

The proposal authors are encouraged to consider these alternative design ideas, and pitch a modified version of the proposal to the community.

Swift Forums

Gutley pitched an idea to implement a solution to catch unwanted uses of ~= on OptionSet.

Johannes Auer pitched a proposal to add AsyncValue.

While migrating a project to the new async features of Swift I constantly needed a mechanism for a synchronization point based of the availability of some value. As far as I can tell, currently there is nothing in the stdlib to cover this.

Basically, this is something like an ‘AsyncSequence’ with only 1 value.

Michael Housh shared a story about exploring Swift web frameworks.

Jonathan G. pitched an idea to add sub-syntax for string literals.

The idea is a new feature for multi-line string literals that allows the user to specify what format the nested content should conform to. Swift would provide a String.Syntax enumeration that would allow the programmer to choose amongst a wide range of existing formats to designate the string content as conforming to.

Ashley Garland started a thread about improving Swift’s user experience from the command line across all platforms.

I’d like to make the command line interface more appropriate for direct, interactive use by humans, while keeping automation use cases available. I propose to rework the CL tools in the following ways:

• Give users direction in accomplishing their Swift tasks at the command line, providing choices for high level tasks and > * clarification about what to do next where possible.
• Progressively disclose flags and options, keeping text focused on the current task.
• Make the command line aware of context so it can infer the right action for impactful cases.
• Continue to provide explicit invocations for all of the tasks we perform today.

Not a Kitteh pitched an idea to add a testable visibility specifier instead of internal for @testable.

@testable is a very useful feature, however I’ve recently had several bugs caused by accidentally accessing internal symbols, or rather, by forgetting to declare symbols in a framework public.

So, I’m wondering if it was a mistake to make @testable allow access to all symbols with internal visibility, and whether it should be changed to just provide access to symbols that are explicitly marked with a special testable visibility.

For all other intents and purposes, testable would be identical to internal. The only difference would be that @testable import only makes testable symbols accessible, all symbols marked as internal stay in-accessible.

Finally