Issue #151 16 Jan 2020
Written by: Kristaps Grinbergs
The holidays are over and during that time a lot has happened.
- Swift 5.2 nightly builds are now available
- folks have discussed and compared Swift and C++
- a book about Swift by Swift community members and creator of Swift Chris Lattner was released — and all proceeds go to charity!
But now let’s enjoy the news!
Interested in sponsoring Swift Weekly Brief? Learn more here.
- SR-11989 Better diagnostic for invalid
enclosing selfproperty wrapper subscript
- SR-12005 [Compiler] Add a smaller test case for AudioKit crash in 5.1
- SR-12022 [Compiler] Refactor
LiteralExprsubclasses to combine common initializer code paths
In episode 83 of Swift Unwrapped, Jesse and JP discuss Modify Accessors.
News and community
Xcode 11.3.1 was released. It included some improvements, like:
- inspection of global variables in Swift
- reduced the size of dependency files (
.d) produced by the Swift compiler.
Sad news that Vapor Cloud will be shutting down on February 29th, but there are many good alternatives.
Commits and pull requests
Feedback was positive, and the proposal is accepted. Thanks to everyone who participated!
Feedback was sparse, but we had generally positive feedback during the first round of review. Therefore the proposal has been accepted with modifications, local binary targets will not be able to reference zipped artifacts.
Proposals in review
#fileevaluates to a string literal containing the full path to the current source file. We propose to instead have it evaluate to a human-readable string containing the filename and module name, while preserving the existing behavior in a new
Swift has a beautiful concise yet expressive syntax. As part of that, escaped identifiers are adopted to allow usage of reserved keywords. This proposal wants to extend the character allowance for escaped identifiers with more Unicode scalars, like whitespace and punctuation. It will enable to have method names (or other identifiers) with a more readable and natural language like the following:
func test validation should succeed when input is less than ten ()
Currently, each catch clause in a do-catch statement may only contain a single pattern and where clause. This is inconsistent with the behavior of cases in switch statements, which provide similar functionality. It also makes some error handling patterns awkward to express. This proposal extends the grammar of catch clauses to support a comma-separated list of patterns (with optional where clauses), resolving this inconsistency.
Swift-evolution thread: Thread
I recently began a personal project in which I wanted to use Kubernetes (K8s) & Swift. To get started I created a library that was going to house all the K8s types, and the HTTP Client for communicating with the K8s API. With the goal of importing this library into all the other projects I had planned. Lucky enough for me, K8s uses the OpenAPI Spec, so generating the client code should be easy. I was mistaken, for Swift that is not the case. Specifically for any Swift client that you wanted to run on Linux. At the time of writing this, there did not exist a Swift Client that the Open-API code generation tool could generate that could be ran on Linux. I had concluded, with the help of others, that if I wanted a Pure-Swift Kubernetes library that could be ran on Linux I would have to write the HTTP Client code myself.
Gor Gyolchanyan pitched an idea about passing custom getter and setters to a property wrapper initializer.
A lot of use cases for property wrappers (like SwiftUI’s
@Bindingor a simple
@Lazy) rely on custom accessor closures of the form
() -> WrappedValueand
(WrappedValue) -> Voidfor the getter and the setter respectively. To that end, I’d like to suggest an improvement to the property wrapper mechanism to help improve the readability of such use cases.
Sergej Jaskiewicz shared a proposal to handle future cases of enums in libraries without binary stability concerns.
SE-0192 introduced a mechanism to add new cases to enums defined in the standard library and overlays in a source-compatible way. SE-0260 later lifted this restriction, allowing to use this mechanism in all libraries built in library evolution mode.
We propose to remove this restriction completely by:
- allowing all library authors to mark their public enums as @frozen;
- warning the clients that exhaustively switch over a non-frozen enum declared in another module, * suggesting them to add an @unknown default case.
The motivation is pretty much the same as SE-0009
That is, we need a shorter form of self.property that is more readable at the point of use.
The idea is:
Add fallback lookup for identifier starts with single
_(ex. _name), if the identifier is not a local variable, member property or global variable, then treat it as self.(identifier without
_) (ex. self.name)
I once a while check Swift benchmarks against other languages to see how the language is speeding.
Why is Swift so awful in Regex and Binary Trees?
Swift is missing a great many data types (see Adding more data structures to the standard library). I thought I may be able to get this going with suggesting the introduction of a
LinkedListtype to Swift.
Tuples in Swift currently lack the ability to conform to protocols. This has led many users to stop using tuples altogether in favor of structures that they can them conform protocols to. The shift from tuples to structures have made tuples almost feel like a second class type in the language because of them not being able to do simple operations that should just work.
Two things from Joe Groff: