A packed week with some exciting announcements. And an Apple event coming up on October 30th. And Swift Unwrapped is back! Cool stuff.
Interested in sponsoring Swift Weekly Brief? Learn more here.
- SR-8788 [Compiler] Rethrowing/convenience initializer does not compile
- SR-8811 [Compiler] Diagnosing Implicit Accessors for Uninhabited Types Should Be Smarter
- SR-8905 [Standard Library] Gaps in String benchmarking
- SR-8908 [Standard Library] Add
Swift Unwrapped is back! In episode 67, Jesse and JP discuss Raw Strings.
News and community
FoundationDB has announced official Swift bindings!
Jetbrains added support for the Swift Package Manager in their C IDE, CLion.
Richard Wei wrote a manifesto on first-class automatic differentiation in Swift, written for both the machine learning community and the Swift programming language design community, with a strong focus on language design.
Commits and pull requests
The core team feels this is an important addition to the language that will open up SIMD programming to a wide audience in an approachable way.
The majority of the feedback received during the thread was regarding the alternate “generic” spelling:
It is still unclear which is the better form. However, in order to better make the decision, the core team has asked the proposal author to implement a prototype showing the alternate form. Reviewers will then be able to try out either form in order to help make the decision.
In addition, the proposal should be revised to spell out more explicitly some of the details, for example, of what masks are and the role they play.
Proposals in review
Optionals are a key feature of Swift and a powerful tool that seamlessly interacts with code. In particular, they serve a great means in expressing “act accordingly if there’s a value, skip otherwise”. Some vivid examples of such behavior are optional chaining, optional invocation
if let, optional patterns, optional assignments and
guard let. This proposal considers further supporting this convenience in
At Apple we are making it a priority to support high-quality tooling for all Swift developers, including those working on non-Apple platforms. We want to collaborate with the open-source community and focus our efforts on building common infrastructure that can be shared by Xcode and other editors and platforms.
To that end, I’m excited to announce that we are going to start a new open-source project for a Swift and C-family language service based on the Language Server Protocol. We’ve chosen to adopt LSP so we can benefit from its active community and wide adoption across other editors and platforms. This means that Visual Studio Code, Atom, Sublime Text, or whatever your favorite editor happens to be, can use the same service as Xcode, and any improvements we make to the service will benefit them all.
To add to what Ben mentioned, the new service will be written in Swift so it could use SwiftSyntax and any other functionality written on top of SwiftSyntax, like formatting.
We’ve started testing the ABI stability of the Swift standard library as part of Swift regression testing.
[It] will check whether the change has broken the ABI stability of a previously checked-in baseline. If it does, a test failure will occur in
stability-stdlib-abi.swift. To resolve this test failure, we can either update the expected ABI breakage list in
stability-stdlib-abi.swift.expectedor update the PR to remedy those breakages.
Steve Canon pitched [a proposal(https://forums.swift.org/t/comparable-and-floatingpoint-types/16886) regarding comparability of Floating point types.
Equatableprotocols want to imply a total order. This is mostly satisfied by
FloatingPointtypes, except for the behavior with
NaNs. A total order requires that for any
a ≤ bor
a ≥ bis true. But IEEE 754 requires that if either
NaN, both of those comparisons are false.
How to write a proposal.