Issue #148 21 Nov 2019
Written by: Bas Broek
I’ve been having a great last two weeks, including a trip to Spain for work — it’s always great to talk to the people in remote locations and meeting up with them in person.
I also feel (like some of you, probably) that the holidays are really just around the corner. Swift Weekly Brief will be here for another two issues this year; so don’t worry about that.
Speaking of the holiday feeling, it seems like a lot of interesting things are still going on when it comes to Swift, as you can read about below.
Three new books from the teams at raywenderlich.com: SwiftUI by Tutorials, Combine: Asynchronous Programming with Swift, and Catalyst by Tutorials. Build fluid and engaging declarative UI for your apps with SwiftUI, master native asynchronous programming with Swift using the Combine framework and run iOS apps natively on macOS with Catalyst!
- SR-11724 [Compiler] Provide a diagnostic when a closure parameter is declared with type sugar
- SR-11729 [llbuild] Add Chromium Tracing as export format option to
- SR-11730 [llbuild] Improve GraphViz as export format option to
- SR-11795 [Compiler] Replace
macOSpretty much everywhere
News and community
Commits and pull requests
We had a uniformly positive response to the idea of supporting binary dependencies in SwiftPM and the high-level design, but there are a number of concerns that came up during review:
The option for disallowing binary dependencies was broadly considered to not provided enough value to be included. It would also be good to clarify in the proposal that opt-in/opt-out functionality can still be provided by clients of libSwiftPM as a workflow feature.
Storing the checksum in the resolved file was seen redundant by some folks. If a revision choses to omit this, we should instead propose to verify the commit hash that is already stored there to achieve similar results.
Several posts mentioned that the API could be simplified and it would make sense to reduce the complexity here since it isn’t needed for the scoped down version of the initial pitch that is being proposed here.
A number of points should be spelled out more concretely in the proposal: verifications of the contents of the artifacts, the concrete layout of the ZIP file and the behaviour if there is no artifact available for the target platform.
Mirror support for this feature should be considered. That should include adding a new command for specifying mirrors for binary artifacts.
Proposals in review
Packages should be able to contain images, data files, and other resources needed at runtime. This proposal describes SwiftPM support for specifying such package resources, and introduces a consistent way of accessing them from the source code in the package.
We can use a
Range<Index>to refer to a group of consecutive positions in a collection, but the standard library doesn’t currently provide a way to refer to discontiguous positions in an arbitrary collection. I propose the addition of a
RangeSettype that can store any number of positions, along with collection algorithms that operate on those positions.
This proposal changes associated type inference behavior to short-circuit a large amount of inference work in the case where the conforming type defines a generic parameter with the same name as an associated type.
This breaks source compatibility with certain valid programs; in Swift 5.1, it is possible for an associated type and a generic parameter with the same name to have different types. However, the name lookup behavior in this case was already very fragile.
There is always a tradeoff between safety and performance when writing reusable code. Low level code either has to make assumptions about the values being passed to it (e.g. a value is non-zero, or an array is non-empty) or it has to check those assumptions. When these functions call one another, but could also be called from the outside, you often find them repeatedly performing the same check.
For Swift to be successful as a systems programming language, it needs to allow efficient use of the synchronization facilities provided by the underlying computer architecture and operating system, such as primitive atomic types or higher-level synchronization tools like
os_unfair_lock. Such constructs typically require us to provide a stable memory location for the values they operate on.
Swift provides a number of language and runtime constructs that are guaranteed to have a stable memory location.
However, Swift does not currently provide ways to reliably retrieve the address of the memory location backing these variables – with the exception of dynamic variables, where all access is done through an explicit unsafe pointer whose value is (obviously) known to the code that performs the access.