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.
- SR-11574 [Compiler] Using
throwsshould have a better diagnostic
- SR-11580 [SwiftSyntax]
IntegerLiteralExprSyntaxshould have comuted properties that return their
- SR-11588 [Compiler] Warn about
Hashableimplementation if there’s a custom
Jesse and JP discussed the Standard Library Preview Package.
Commits and pull requests
If you’re working on a build system and you’re implementing the “
-emit-modulefirst, then build” optimization, try adding
This proposal suggests a new initializer for
Stringthat provides access to a String’s uninitialized storage buffer.
Stringtoday 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
String, which currently uses standard library internals to get good performance when using
CFStringGetBytes. Another, also from the standard library, is
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
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-185 introduced synthesized, opt-in
Hashableconformances for eligible types. Their sibling protocol
Comparablewas left out at the time, since it was less obvious what types ought to be eligible for a synthesized
Comparableconformance and where a comparison order might be derived from. This proposal seeks to allow users to opt-in to synthesized
enumtypes 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
enumcases, and then the lexicographic comparison order of the associated values for an
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,
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.
This prototype demonstrates two main protocols,
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:
- Consumers: nibbling off the front or back of a Collection
- Searchers: finding a needle in a haystack (i.e. a Collection)
- Validators: constructing types in the process of consuming/searching
- 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.
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.
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
Hashablethat I’ve wanted to confer on my tuple typed keys.
With halloween around the corner, take a look at this spooky quiz! 👻