Welcome to the 113th issue of Swift Weekly Brief! This week was more calm, no news explosions. The repositories and Swift.org discussions had their usual activity.

Starter tasks

  • SR-8135 [Package Manager] SwiftPM should only check for clang if it is needed
  • SR-8137 [Package Manager] Provide mechanism to disable color diagnostics from commands
  • SR-8138 [Package Manager] Mechanism to limit the parallelism of swift test --parallel
  • SR-8139 [Package Manager] Executable init template is broken when there is a dash in package name
  • SR-8173 [Tooling] (T) Reported as Single-Element Tuple Rather Than T
  • SR-8190 [Standard Library] Introduce a RingBuffer to the Standard Library
  • SR-8204 [Package Manager] Sort targets in SwiftPM generated Xcode project
  • SR-8222 [Swift for TensorFlow] PartitionCloner::visitCondBranchInst() should be generalized to handle TensorHandle<Bool> in addition to TensorHandle<Builtin.i1>

Submit a task by sending a pull request or opening an issue.

Swift Unwrapped

In episode 65, Jesse and JP discuss the SE-0213: Literal initialization via coercion proposal and its implementation.

News and community

Ankit Aggarwal noticed the right thing: when Codable is awesome, it requires so much boilerplate to support enums. It would be great if the compiler could synthesize it, like with Hashable and Equatable.

Commits and pull requests

Mark Lacey opened a pull request to remove Swift 3 from the type checker. “Goodbye, Swift 3”

Slava Pestov merged several pull requests: #17611, #17651 and #17816 - great additions to SE-0156: Class and Subtype existentials to add support for protocols with superclass constraints.

Tony Allevato merged a pull request to add Unicode properties to Unicode.Scalar. This implements SE-0211, Add Unicode Properties to Unicode.Scalar.

Accepted proposals

An amendment to SE-0202: Random Unification was accepted.

We decided to accept the proposed amendment to remove randomElement as a customization point.

SE-0216: User-defined dynamically callable types was accepted.

Feedback on the proposal was almost entirely positive on both the idea of supporting dynamically-typed calls and the proposal’s specific approach to providing that support.

Therefore, the proposal was accepted without modifications.

Proposals in review

SE-0217: Introducing the !! “Unwrap or Die” operator to the Swift Standard Library is under review.

This proposal introduces an annotating forced-unwrapping operator to the Swift standard library. It augments the ?, ??, and ! family, adding !!. This “unwrap or die” operator provides code-sourced rationales for failed unwraps, supporting self-documentation and safer development. The !! operator is commonly implemented in the wider Swift Community and should be considered for official adoption.

The new operator benefits both experienced and new Swift users. It takes this form:

let value = wrappedValue !! <# "Explanation why lhs cannot be nil." #>

SE-0218: Introduce compactMapValues to Dictionary is under review.

This proposal adds a combined filter/map operation to Dictionary, as a companion to the mapValues and filter methods introduced by SE-0165. The new compactMapValues operation corresponds to compactMap on Sequence.

SE-0219: Package Manager Dependency Mirroring is under review.

A dependency mirror refers to an alternate source location which exactly replicates the contents of the original source.

Dependency mirroring is useful for several reasons:

  • Availability: Mirrors can ensure that a dependency can be always fetched, in case the original source is unavailable or even deleted.
  • Cache: Access to the original source location could be slow or forbidden in the current environment.
  • Validation: Mirrors can help with screening the upstream updates before making them available internally within a company.

Swift Forums

Tony Parker started a pitch to move URLSession and related types to a new library.

Some of the feedback we’ve received from the SwiftNIO team is that Foundation’s dependency on libcurl brings in too many other libraries.

I propose moving the networking types (except URL and URLComponents) into another library, with a working name of swift-corelibs-foundation-networking.

Benefits:

  • SwiftNIO would be able to use core Foundation types.
  • swift-corelibs-foundation-networking could use SwiftPM to build itself.
  • Other projects that wish to maintain a minimum set of dependencies and do not need networking support can reduce their footprint.

Finally

I wonder if it runs Swift? 🤔