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.
Starter tasks
- SR-11989 Better diagnostic for invalid
enclosing self
property wrapper subscript - SR-12005 [Compiler] Add a smaller test case for AudioKit crash in 5.1
- SR-12022 [Compiler] Refactor
LiteralExpr
subclasses to combine common initializer code paths
Podcasts
In episode 83 of Swift Unwrapped, Jesse and JP discuss Modify Accessors.
In Swift by Sundell #63, John Sundell, Donny Wals and Antoine van der Lee talk about how Swift has changed in 2019, and where things might be headed in 2020.
In Empower Apps #34, Leo Dion and Tim Condon discuss Server-Side Swift and the Vapor Web Framework.
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.
John Sundell shared a great article about the decade of Swift and announced a static site generator built specifically for Swift developers called Publish.
Sad news that Vapor Cloud will be shutting down on February 29th, but there are many good alternatives.
Joe Duffy wrote a blog post about the tool Partial - a type-safe wrapper that mirrors the properties of the wrapped type but makes each property optional.
Always Right Institute wrote a tutorial on SwiftNIO 2.
Slava Pestov shared some insights on how the lines of code in CSDiag.cpp
have decreased between Swift versions.
Commits and pull requests
Doug Gregor made a pull request that he’s calling a little side project and it is coming in at 11x faster than the existing implementation for scanning the dependencies of a Swift file.
Rintaro Ishizaki merged a pull request that improves code completion when using GenericSignature
methods to get associatedtype
requirements.
Cory Benfield created a pull request that adds withContiguousStorageIfAvailable
to SubString.UTF8View
in the Standard Library. This pull request also has a second part.
Erik Eckstein created a pull request that has some code size improvements for Array
in the Standard Library.
Doug Gregor made a work-in-progress pull request that has a refactoring/reimplementation of function builders to make handling declarations possible.
Accepted proposals
SE-0273: Package Manager Conditional Target Dependencies was accepted.
Feedback was positive, and the proposal is accepted. Thanks to everyone who participated!
SE-0272: Package Manager Binary Dependencies was accepted with modifications.
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
SE-0274: Concise Magic File Names is under review.
Today,
#file
evaluates 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#filePath
expression.Swift-evolution thread: Concise Magic File Names, We need
#fileName
SE-0275: Allow more characters (like whitespaces and punctuations) for escaped identifiers is under review.
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 ()
SE-0276: Multi-Pattern Catch Clauses is under review.
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
Swift Forums
Steven Prichard explained his personal experience with Open API Tools & Swift.
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
@Binding
or a simple@Lazy
) rely on custom accessor closures of the form() -> WrappedValue
and(WrappedValue) -> Void
for 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.
Steve K. Chiu pitched how to make self.property
more readable at the point of use.
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)
MasterSwift shared a comparison between Swift and Java.
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?
Wildchild9 described an idea to add a LinkedList
type to the Standard Library.
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
LinkedList
type to Swift.
Alejandro Alonso pitched a proposal and implementation introducing Equatable
conformance for all tuples whose elements are themselves Equatable
.
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.
Finally
Two things from Joe Groff:
- Politics and Swift
- Are Playgrounds radical?