Issue #172 05 Nov 2020
Written by: Kristaps Grinbergs
The last two weeks have been very active. Swift core team shared an article explaining Swift concurrency roadmap and multiple other great resources. I think it will be very exciting to see what is going to happen in near future.
There are awesome news from Swift on the Windows development side. The initial port of the Swift system has merged. It’s great to see Swift reaching new horizons and getting one step closer to total world domination. It is a famous quote by Chris Lattner.
Raycast brings the macOS Spotlight experience to your third-party services. Create issues in Jira, merge pull requests in GitHub, or join Zoom calls directly from your desktop. Extendable with scripts and built for macOS with 100% Swift inside.
News and community
Max Desiatov tweeted that http://swift.org website is not searchable, contains outdated information, and is not translated to any other language. He purposed that it should be open-source. You can head down to the issue and vote there.
Commits and pull requests
This proposal describes result builders, a new feature which allows certain functions (specially-annotated, often via context) to implicitly build up a result value from a sequence of components.
In effect, this proposal allows the creation of a new class of embedded domain-specific languages in Swift by applying builder transformations to the statements of a function. The power of these builder transformations is intentionally limited so that the result preserves the dynamic semantics of the original code: the original statements of the function are still executed as normal, it’s just that values which would be ignored under normal semantics are in fact collected into the result. The use of an ad hoc protocol for the builder transformation leaves room for a wide variety of future extension, whether to support new kinds of statements or to customize the details of the transformation. A similar builder pattern was used successfully for string interpolation in SE-0228.
Result builders have been a “hidden” feature since Swift 5.1, under the name “function builder”, and the implementation (and its capabilities) have evolved since then. They are used most famously by SwiftUI to declaratively describe user interfaces, but others have also experimented with building Swift syntax trees, testing, a Shortcuts DSL, a CSS DSL, and an alternative SwiftPM manifest format. There’s a GitHub repository dedicated to awesome function builders with more applications.
Proposals in review
Amazon Web Services (AWS) is the largest provider of cloud services. Many companies rely on the systems and automation they provide. These include storage, security, identity, messaging, databases, compute, machine learning and analytics to mention a few.
Soto provides a Swift NIO based interface to access all Amazon Web Services.
Swift Concurrency Roadmap
The end state of these changes will:
- make asynchronous programming convenient and clear at the point of use,
- provide a standard set of language tools and techniques that Swift developers can follow,
- improve the performance of asynchronous code through better knowledge at compile time, and
- eliminate data races and deadlocks in the same way Swift eliminates memory unsafety.
The actor model involves entities called actors. Each actor can perform local computation based on its own state, send messages to other actors, and act on messages received from other actors. Actors run independently, and cannot access the state of other actors, making it a powerful abstraction for managing concurrency in language applications. The actor model has been implemented in a number of programming languages, such as Erlang and Pony, as well as various libraries like Akka (on the JVM) and Orleans (on the .NET CLR).
Swift’s concurrency feature involves asynchronous functions and actors. While Objective-C does not have corresponding language features, asynchronous APIs are common in Objective-C, expressed manually through the use of completion handlers. This proposal provides bridging between Swift’s concurrency features (e.g.,
asyncfunctions) and the convention-based expression of asynchronous functions in Objective-C. It is intended to allow the wealth of existing asynchronous Objective-C APIs to be immediately usable with Swift’s concurrency model.
Our approach borrows heavily from the well-received
awaitfeatures in many other languages. I’ve included a portion of the proposal below; the full text can be found here. This feature ties in closely with the proposals for structured concurrency and actors.
Any concurrency design has to provide some way of actually running code concurrently. We propose embracing the approach of structured concurrency, in which concurrent programs are organized into tasks and child tasks rather than simply a sea of formally-unrelated threads and jobs. Structured concurrency allows us to neatly address a large number of systemic problems with task management that would otherwise need a lot of ad hoc support.
I got a chance to write up some thoughts on how to address one of the major challenges with the recent actor model proposal: how do we ensure that values transferred between actors do not introduce shared mutable state.
Reflection can be a useful thing to create convenient and concise APIs for libraries. This proposal seeks to improve the safety of such APIs and to tackle the binary size problem by introducing a mechanism of selectively keeping reflection metadata only for types that need it and dead strip it for all others. Developers will gain an opportunity to express a requirement to have reflection metadata in source-code.
So what does it mean for us? Rest in peace
EventLoopFutures? I realise that it’s just a roadmap and a series of pitches, and things might (will) change a lot, but it’s certainly the future, and it’s unlikely that Swift-NIO would want to ignore it.
As a quick introduction, I need to mention that WebAssembly is a collection of multiple proposals that are at different implementation stages in WebAssembly hosts. The bare minimum is called WebAssembly MVP and is available in all major browsers. Other features such as atomics, SIMD, reference types and many more are not as widely available (with Safari lagging behind in most of these).
The SwiftWasm team would be happy to start experimenting with atomics, SIMD, and reference types when that is possible. Atomics is a big one, as it unblocks multi-threading support with big parts of core libraries that are currently unavailable in SwiftWasm. We could then make Dispatch and major parts of Foundation available in browsers.
A package feed 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 feeds, search them via the swift package command-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 feeds.
Samuel Roth proposed a pitch that introduces an Authentication package, which will provide lightweight yet opinionated abstractions enabling developers to build secure authentication systems in Swift.
As adoption of Swift on the server continues to increase, and the server-side Swift ecosystem grows (e.g. with introduction of Swift Service Discovery), various approaches to building authentication and authorization mechanisms are likely to pop up. Swift Authentication seeks to address the former challenge.
Swift Authentication aims to address sensitive use cases that could have profound security implications. An openly-available package with good documentation (and perhaps more importantly, recommendations) made available in the IDE (Xcode or otherwise) could make Swift an even more attractive solution for building services with authentication requirements.
Codable was introduced in SE-0166. with support for synthesizing Encodable and Decodable conformance for class and struct types, that only contain values that also conform to the respective protocols.
Currently auto-synthesis does not work for enums with associated values. There have been discussions about it in the past, but the concrete structure of the encoded values was never agreed upon. We believe that having a solution for this is an important quality of life improvement.
Provide a course grained actor model first, which includes separate of concerns of actor functions, whose definitions live separately from Actors that register to receive those function calls async.
Provide a fine grained concurrency model allowing queue safe very high frequency lock free allocations, similar to a generational GC.
Provide a concurrency safe logging model. Concurrency safe logging isn’t just not crashing- its safe and performantly managing high frequency logging on n concurrent threads.
This repository gathers student-friendly setup instructions for platforms, editors, and IDEs that support Swift. The goal of this repository is to support the adoption of Swift as a general purpose cross-platform programming language in (higher) education.
To kickstart the repository, I’ve written instructions for the platforms and editors I’m using in an upcoming programming course, notably Visual Studio Code (with SourceKit-LSP and CodeLLDB) on Ubuntu.
The least disruptive and backwards compatible solution appears to be Platform Aliasing, which can reduce an annotation like this…
@available(macOS 10.16, iOS 14.0, watchOS 7.0, tvOS 14.0, *)
…to something as simple as this…
@available(apple 2020, *)