I’ve had a great week in Paris, attending and giving a workshop at FrenchKit. I hope you’ve all had a great week too!

I also wanted to mention that this month is Hacktoberfest, a yearly, month-long celebration of open source software. A perfect time to contribute to (Swift) open source!

And with that, here’s what’s been cookin’ in the last two weeks in terms of Swift.org and other Apple open source projects.

Interested in sponsoring Swift Weekly Brief? Learn more here.

Starter tasks

  • SR-11574 [Compiler] Using try instead of throws should have a better diagnostic
  • SR-11580 [SwiftSyntax] FloatLiteralExprSyntax and IntegerLiteralExprSyntax should have comuted properties that return their Int/Float value
  • SR-11588 [Compiler] Warn about derived Hashable implementation if there’s a custom Equatable

Podcasts

Jesse and JP discussed the Standard Library Preview Package.

Commits and pull requests

Bruno Rocha merged a pull request adding support for local refactoring of Swift code in SourceKit-LSP!

Zoe Carver opened a pull request with optimizations for Swift that enables constant-folding of string comparisons.

Harlan Haskins merged a pull request that adds an experimental flag to skip non-inlinable function bodies and turns it on for the standard library and overlay .swiftmodules.

If you’re working on a build system and you’re implementing the “-emit-module first, then build” optimization, try adding -Xfrontend -experimental-skip-non-inlinable-function-bodies.

Returned proposals

SE-0263: Add a String Initializer with Access to Uninitialized Storage was returned for revision.

This proposal suggests a new initializer for String that provides access to a String’s uninitialized storage buffer.

String today is well-suited to interoperability with raw memory buffers when a contiguous buffer is already available, such as when dealing with malloced C strings. However, there are quite a few situations where no such buffer is available, requiring a temporary one to be allocated and copied into. One example is bridging NSString to String, which currently uses standard library internals to get good performance when using CFStringGetBytes. Another, also from the standard library, is Int and Float, which currently create temporary stack buffers and do extra copying. We expect libraries like SwiftNIO will also find this useful for dealing with streaming data.

Proposals in review

SE-0265: Offset-Based Access to Indices, Elements, and Slices is under review.

This proposal introduces OffsetBound, which can represent a position in a collection specified as an offset from either the beginning or end of the collection (i.e. the collection’s “bounds”). Corresponding APIs provide a more convenient abstraction over indices. The goal is to alleviate an expressivity gap in collection APIs by providing easy and safe means to access elements, indices, and slices from such offsets.

SE-0266: Synthesized Comparable conformance for enum types is under review.

SE-185 introduced synthesized, opt-in Equatable and Hashable conformances for eligible types. Their sibling protocol Comparable was left out at the time, since it was less obvious what types ought to be eligible for a synthesized Comparable conformance and where a comparison order might be derived from. This proposal seeks to allow users to opt-in to synthesized Comparable conformances for enum types without raw values or associated values not themselves conforming to Comparable, a class of types which I believe make excellent candidates for this feature. The synthesized comparison order would be based on the declaration order of the enum cases, and then the lexicographic comparison order of the associated values for an enum case tie.

Swift Forums

Doug Gregor announced a Swift compiler driver reimplementation in Swift!

The swift-driver project is a new implementation of the Swift compiler driver that is intended to replace the existing driver with a more extensible, maintainable, and robust code base. The Swift compiler’s driver is what handles the build of a Swift module: it runs the Swift compiler frontend to compile source code to object files, the linker to link those object files into a library or executable, and so on, and contains much of the knowledge of how to produce working programs for any given platform. The driver is the main program that build systems (e.g. SwiftPM, xcodebuild, make, ninja) interact with to compile Swift code, so it is a key piece of infrastructure for building Swift code. The new swift-driver is architected as a Swift library, allowing for deeper integration with the Swift Package Manager.

Michael Ilseman pitched a proposal for protocol-powered generic trimming, searching, and splitting Collections.

This prototype demonstrates two main protocols, CollectionConsumer and CollectionSearcher, and a suite of API generic over them.

Native regex literals will be built on top of generic functionality and used with generic APIs. These can be broken down into 4 stages:

  1. Consumers: nibbling off the front or back of a Collection
  2. Searchers: finding a needle in a haystack (i.e. a Collection)
  3. Validators: constructing types in the process of consuming/searching
  4. Destructuring Pattern Matching Syntax: Like ~=, but can bind a value

Each stage delivers important API and syntax improvements to users alongside powerful extension points for libraries. Native regex literals would conform to these protocols and leverage new syntax, allowing them to be used by the same generic APIs.

This prototype covers stages 1 and 2.

Jon Gilbert pitched a proposal to add support for Compositional Initalization.

This proposal introduces an opt-in protocol, PropertyInitializable, which provides two new init methods:

  • failable init from a collections of extensible, typesafe keypath-value Property objects
  • non-failable init to clone from another instance, mutating select properties

The name “compositional init” means that this proposal allows the state of an object or struct to be assembled compositionally from sets of properties (including another instance). Compositional initialization allows mutations to be encapsulated in a clear, type-safe way.

Gustaf Kugelberg pitched a proposal to introduce ExpressibleByTupleLiteral instead of tuples conforming to protocols.

As can be seen from the forum history, many people have suggested ways to make it possible to conform tuple types to protocols. It is perhaps most natural when the conformance can be synthesized, - in my personal usage it’s certainly conformance to Equatable and Hashable that I’ve wanted to confer on my tuple typed keys.

Finally

With halloween around the corner, take a look at this spooky quiz! 👻