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.

Starter tasks

  • 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 llbuild-analyze
  • SR-11730 [llbuild] Improve GraphViz as export format option to llbuild-analyze
  • SR-11795 [Compiler] Replace OSX with macOS pretty much everywhere

News and community

Steve Cannon wrote a blog post on swift.org on Swift Numerics, a new open source project, partially in lieu of an implementation for SE-0246.

Ted Kremenek announced Swift 5.1.2, which includes an improved type-checking algorithm that has significant performance benefits on code using function builders (such as SwiftUI code).

Saleem Abdulrasool gave a talk on bringing Swift to Windows.

Alexis Beingessner wrote a blog post on how Swift achieved dynamic linking support.

Steve Hawley announced Binding Tools for Swift, which allows C# to interoperate with Swift!

Saleem Abdulrasool announced that all core libraries have been migrated to modern CMake (3.51.1).

Commits and pull requests

Zoe Carver is working on a pull request turning sequences of String comparisons into a fast switch.

Becca Royal-Gordon is working on a pull request to make Swift #file strings include only the base name of the file, making them a lot easier to digest.

Slava Pestov merged a pull request that fixes a Self type bug that required a mere 1000 line refactoring first. 😅

Returned proposals

SE-0272: Package Manager Binary Dependencies was returned for revision.

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

SE-0271: Package Manager Resources is under 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.

SE-0270: Add Collection Operations on Noncontiguous Elements is under review.

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 RangeSet type that can store any number of positions, along with collection algorithms that operate on those positions.

Swift Forums

Slava Pestov pitched a proposal to infer associated types as generic parameters more eagerly.

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.

Jon Hull pitched a proposal for Runtime Type Guarantees.

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.

Karoy Lorentey pitched a proposal to expose the Memory Locations of Class Instance Variables.

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 pthread_mutex_t or 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.

Finally

Formatting
   is
 hard.