I think I don’t have to mention much more than that a lot of fantastic information on the distant future of Swift has been shared in the last two weeks: the road to Swift 6, progress on the Function Builders proposal, and more. 🎉🎉🎉

This is a big issue with lots of interesting topics being discussed!

Interested in sponsoring Swift Weekly Brief? Learn more here.

Starter tasks

  • SR-12085 [Compiler] Clean up TypeCheckType so it never returns Type()
  • TF-1107 [Autodiff] Add JVPs to standard library

News and community

Ted Kremenek shared an update on the road to Swift 6, with many interesting insights. If there’s one thing you’re going to pick up from this issue, it should be this — it’s a great read. Some things mentioned:

  • Faster builds
  • More informative and accurate diagnostics
  • Reliable and fluid debugging experience
  • Provide excellent solutions for major language features such as memory ownership and concurrency
  • Significantly improve the performance of incremental builds
  • Improve code completion performance, reliability, and experience

Like I said; you’re going to want to give this a read.

JP Simard created a poll about the oldest Swift version people are actively using; a quite surprisingly high amount (to me) is pretty up-to-date with the latest Swift versions!

Mattt announced swift-doc, an (experimental) command-line utility for generating documentation for Swift projects. One of the distinguishing features of swift-doc is that it operates on Swift code at a syntactic level, without first compiling it.

George Barnett released SwiftNIO 2.13.0.

Commits and pull requests

Pavel Yaskevich merged a pull request that is a big step toward improving type inference for closures over time.

Doug Gregor merged a bunch of pull requests:

  • #29331 is a large refactor he’s been doing on-and-off for a while. By itself it has no user-visible effect, but it’s the building block to make function builders more powerful and expressive.
  • #29409 makes supporting multiple conditions for if statements within function builder closures a straightforward generalization of the refactored code. This would have required some gross hackery with the old implementation of function builders.
  • #29419 adds support for if #available within function builders.

All this is part of a much larger effort to improve function builders, and this post explains this effort further.

Accepted proposals

SE-0276: Multi-Pattern Catch Clauses was accepted.

Feedback was almost universally positive, and the proposal has been accepted! Thank you to everyone who participated in the review process.

Rejected proposals

SE-0275: Allow more characters (like whitespaces and punctuations) for escaped identifiers was rejected.

The core team has decided to reject this proposal. Community reaction was mixed, and many of the people both supporting and rejecting the idea had concerns about the breadth of the set of characters this allows. Allowing more characters in identifiers would also add complexity to tooling, including syntax highlighting, IDEs, and runtime reflection libraries, which would need to be able to recognize quoted identifiers, know when identifiers would need to be quoted for presentation purposes, and potentially need to implement more elaborate parsing and escaping rules to handle these generalized identifiers. In the core team’s judgment, this added demand on tooling is not justified by the amount of utility provided by the proposal.

Proposals in review

SE-0274: Concise magic file names is under a second review.

The original review thread concluded with the core team accepting the proposal in principal: #file will be updated to include only the file and module names, with #filePath introduced for use cases that require the full path to the file.

However, during the review it was proposed that the exact format of #file be specified, in order to allow for future tooling to rely on that format to determine the file and module name from the string.

The proposal has been amended to explicitly include this format, and this re-review is focused on that aspect of the proposal.

Changes since the first review

  • We now specify that the #file string will have the format <module-name>/<file-name> (with a second form for future expansion) and discuss how to parse it. The previous revision left this format as a compiler implementation detail that tools should always treat as opaque.
  • We now discuss the behavior of #sourceLocation’s file parameter and provide for a warning when it creates conflicts. The previous revision did not discuss these topics.
  • We now mention the need for tooling to map #file strings back to paths.
  • We now provide for a warning when a wrapper around a #filePath-defaulting function passes it #file instead, or vice versa. The previous revision did not discuss this.
  • We have added several suggestions from the first review to the “alternatives considered” section to explain why we aren’t proposing them.

SE-0270: Add Collection Operations on Noncontiguous Elements is under a third review.

We can use a Range<Index> to refer to a group of consecutive positions in a collection, but the standard library doesn’t currently provide a way to refer to discontiguous positions in an arbitrary collection. I propose the addition of a RangeSet type that can represent any number of positions, along with collection algorithms that operate on those positions.

There are varied uses for tracking multiple elements in a collection, such as maintaining the selection in a list of items, or refining a filter or search result set after getting more input from a user.

The Foundation data type most suited for this purpose, IndexSet, uses integers only, which limits its usefulness to arrays and other random-access collection types. The standard library is missing a collection that can efficiently store ranges of indices, and is missing the operations that you might want to perform with such a collection. These operations themselves can be challenging to implement correctly, and have performance traps as well — see last year’s Embracing Algorithms WWDC talk for a demonstration.

Swift Forums

Frederick Kellison-Linn pitched a proposal to allow chained member references in implicit member expressions.

I propose that we extend implicit member syntax (a.k.a. “leading dot syntax”) to allow for chained member references rather than just a single level.

When the type of an expression is implied by the context, Swift allows developers to use what is formally referred to as an “implicit member expression”, sometimes referred to as “leading dot syntax”:

class C {
    static let zero = C(0)
    var x: Int

    init(_ x: Int) {
        self.x = x
    }
}

func f(_ c: C) {
    print(c.x)
}

f(.zero) // prints '0'

However, attempting to use this with a chain of member references fails:

extension C {
    var incremented: C {
        return C(self.x + 1)
    }
}

f(.zero.incremented) // Error: Type of expression is ambiguous without more context

On master, the new diagnostic system has improved the produced error:

f(.zero.incremented) // Error: Cannot infer contextual base in reference to member 'zero'

but the same problem persists.

Yuta Koshizawa pitched a proposal: Three Steps to Variadic Generics.

Variadic generics was referred to in “On the road to Swift 6”. I think it may be a good idea to break down it into the following three steps compared to tackle variadic generics directly.

  1. Operations for tuples
  2. Variadic tuples
  3. Variadic generics

Fabian Fett announced official platform support for other Linux Distributions (besides Ubuntu).

The SSWG announced that they are looking for other Linux Distributions besides Ubuntu to support official prebuilt toolchains for in their yearly update.

After some research the only documented way I found to engage in widening the platform support is by administering a Jenkins slave that builds Swift on a given platform as part of the Community-CI effort.
Sadly administering such a slave comes with at least a monetary burden (besides time and security).

For this reason I want to ask: What will the process be to become an officially supported platform? If there is no process planned so far maybe we can start a discussion here.

Rahul Malik pitched a proposal to add SwiftPM support for Swift scripts.

Swift is a general-purpose language that aims expand it’s availability and impact on various domains and platforms. We believe great scripting support and experience is an important part of improving the impact of Swift as a language. Swift already includes basic support for scripting via the Swift command-line tool. This is a proposal for greatly improving the script support by providing a deeper integration with the Swift Package Manager.

Steve Canon pitched a proposal to add Float16.

Introduce the Float16 type conforming to the BinaryFloatingPoint and SIMDScalar protocols, binding the IEEE 754 binary16 format (aka float16, half-precision, or half), and bridged by the compiler to the C _Float16 type.

David Hart pitched a proposal to add Localized Resources to the Swift Package Manager.

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.

Nikhil Pandey pitched a proposal for a push towards distribution and promotion of the Server Side Swift Framework.

Lots of efforts are being made for creation of new frameworks and creating new libraries since last few years for making Swift on Server Side a real success, which is commendable. Let’s also accept the fact that Server Side Swift is also something which requires cooperation and support of wider developer community outside Apple ecosystem too, especially on Linux side and, so cooperation with external developers is also a requirement.

A time has come for putting efforts also towards promotion and distribution of Server Side Swift too.

Owen Voorhees shared an update on swift-driver and –help / documentation lookup.

In short, I think we should consider adding writing a swift-help in Swift as part of the swift-driver project, and use it to entirely replace help handling in the compiler sooner rather than later. The benefits are:

  • We’d gain experience integrating a Swift package product in compiler toolchains with minimal impact on day-to-day development. Anything we learned could then be applied to swift-driver later on. No bootstrapping would be needed since the help text isn’t needed to build the compiler.
  • swift help becomes a supported subcommand
  • It solves my immediate problem (admittedly not a strong justification)
  • We could delete a little bit of C++ from the frontend :)

Nevin pitched a proposal to add support for set-only subscripts.

Currently, subscripts can be read-only or they can be read-write, but there is no way to declare a subscript as write-only. Write-only subscripts have a number of important uses, and this proposal aims to bring them into the language.

Finally

#nofilter.