On this day, exactly five years ago, Apple open-sourced the Swift programming language! Imagine how fast this language has moved, and what the next five years will bring.
We have some excellent news for server-side Swift development. Starting with the introduction of SwiftNIO SSH and an early version of Docker Desktop running on Apple Silicon, we can add Mac instances for EC2 which are now available from Amazon Web Services. I think this will open even more doors for Swift, and let developers build great products in even more places!
This week’s issue is supported by Dave Verwer, who publishes iOS Dev Weekly every Friday and co-created the Swift Package Index. He’s been a big advocate for the Weekly Brief since it started, and is supporting us because he wants to see it continue. Thanks Dave!
- SR-13899 [Compiler] Missing conditional cast fix-it
- SR-13903 [Compiler] Make
In episode 86 of the Swift by Sundell podcast, Daniel Steinberg joins John to discuss how various functional programming patterns can be adopted in Swift, and how many of those patterns can be found in both the standard library and in frameworks like Combine and SwiftUI.
News and community
Introducing SwiftNIO SSH, a collection of APIs that allow programmers to implement SSH-speaking endpoints.
SwiftNIO SSH is a programmatic implementation of SSH: that is, it is a collection of APIs that allow programmers to implement SSH-speaking endpoints. Critically, this means it is more like libssh2 than openssh. SwiftNIO SSH does not ship production-ready SSH clients and servers, but instead provides the building blocks for building this kind of client and server.
Function overloading is a powerful tool that enables us to define multiple functions of the same name with different implementations: in this article we’ve covered how Swift addresses ambiguity and how > we can (cautiously) use the
@_disfavoredOverloadattribute in case of multiple matches.
Commits and pull requests
Robert Widmann merged a pull request that adds a new Fingerprint currency type that centralizes a bunch of hashing invariants and gives me some room to try to experiment with different hashing regimes.
Based on the feedback from the pitch and first review, the core team feels the ideas behind Package Collections are useful and put the Swift Packages ecosystem on the right path.
However, during the first review, several community members requested to learn more about the Package Collection data format. The core team felt the proposal should be amended to explicitly call out if the data format is part of the feature specification or not, and provide reasoning for its inclusion or exclusion.
Proposals in review
This is a proposal for adding support for Package Collections to SwiftPM. A package collection is a curated list of packages and associated metadata which makes it easier to discover an existing package for a particular use case. SwiftPM will allow users to subscribe to these collections, search them via the
swift package-collectionscommand-line interface, and will make their contents accessible to any clients of libSwiftPM. This proposal is focused on the shape of the command-line interface and the format of configuration data related to package collections.
Property Wrappers were introduced in Swift 5.1, and have since become a popular mechanism for abstracting away common accessor patterns for properties. Currently, applying a property wrapper is solely permitted on local variables and type properties. However, with increasing adoption, demand for extending where property wrappers can be applied has emerged. This proposal aims to extend property wrappers to function and closure parameters.
As a compiled programming language with a modern type system, Swift has a unique opportunity to develop its own numerical computing and ML ecosystem. Driven by the growing needs of ML libraries and algorithms, we believe one key technology, differentiable programming, will help push ML development experience and developer productivity to a whole new level.
The motivation for the upcoming deprecation is the fact that starting Xcode 11, opening and building packages is directly supported by Xcode and therefore we believe that generate-xcodeproj no longer provides material value.
The PR generated some interesting follow-on discussion on how folks are still using generate-xcodeproj, and this thread is an RFC to track such use cases and see how they can be best addressed.
We posted the first drafts of a number of proposals related to Swift concurrency a few weeks ago. At this time of this writing, the forum topics directly related to the concurrency proposals have more than 600 posts in total (!), which includes lots of great ideas for design improvements, requests for clarification, and so on.
Joe Newton pitched an idea to add inline
@convention(…) attributes for closures.
Owen Voorhees pitched a proposal to adding some
swift package subcommands for making mechanical edits to the
Because Swift package manifests are written in Swift using the PackageDescription API, it is difficult to automate common tasks like adding a new product, target, or dependency. This proposal introduces new
swift packagesubcommands to perform some common editing tasks which can streamline users’ workflows and enable new higher-level tools.
When working on code where I’m doing a lot of calculation in geometric spaces such as layout, animation, or color, I often find myself using the concept of a floating point interval: a closed range on the floating point number line. However, the existing ClosedRange requires its bounds to be ordered, which makes it less than useful for geometric calculations where a coordinates can travel or be interpolated in either direction.
I recently came across Daniel Lemire’s work on fast UTF8 validation. Given that Swift needs to UTF8-validate nearly every string that is e.g. read from a SQLite database, I was wondering whether it would be possible and worthwhile to use Lemire’s work for speeding up Swift’s current UTF8 validation code.
Chris Lattner asked “why should actors support subclassing?”.
One hotly debated thing in the recent actor proposal is whether it should be
actor. I think there is a more fundamental question, which is basically “why should actors support subclassing?”
I wrote up some thoughts on this in this whitepaper: Actors are reference types, but why classes?
Dan Zheng posted a pitch for improving the type system to make Swift code safer in certain cases. One application of this could be type-safe lists, but there’s certainly more we could do with it. He also asked two great questions about ownerships in Swift.
The proposed solution is to consider protocol conformances to be a source of throwing behavior for
rethrowsto reason about the throwing behavior of user operations provided via protocol conformances.
Swift’s proposed async/await feature provides an intuitive, built-in way to write and use functions that return a single value at some future point in time. We propose building on top of this feature to create an intuitive, built-in way to write and use functions that return many values over time.