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.
- SR-8135 [Package Manager] SwiftPM should only check for
clangif 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
- 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
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
Commits and pull requests
We decided to accept the proposed amendment to remove
randomElementas a customization point.
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
This proposal introduces an annotating forced-unwrapping operator to the Swift standard library. It augments the
!!. 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:
This proposal adds a combined
Dictionary, as a companion to the
filtermethods introduced by SE-0165. The new
compactMapValuesoperation corresponds to
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.
Some of the feedback we’ve received from the SwiftNIO team is that Foundation’s dependency on
libcurlbrings in too many other libraries.
I propose moving the networking types (except
URLComponents) into another library, with a working name of
- SwiftNIO would be able to use core Foundation types.
swift-corelibs-foundation-networkingcould 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.