Issue #192 26 Aug 2021
Written by: Kristaps Grinbergs
This week I spoke at the 360iDev conference. I enjoy going to conferences and meeting fellow community members, but it is tough to do it in a remote environment. The organizers did a tremendous job to facilitate both worlds this year. Thank you!
The last two weeks were relatively silent in the open-source Swift world. But we have news that one of the maintainers of this newsletter, Bas Broek, might join this project in the future. :) If you want to participate by helping out or writing an issue, just reach out to us. This is by no means a personal project.
We have sponsorship availability for upcoming dates. Your support would be greatly appreciated by more than 10K Twitter followers and 4.5K newsletter subscribers! Head down here to learn more about how you could support this project. Thank you!
Interested in sponsoring Swift Weekly Brief? Learn more here.
In episode 103 of the Swift by Sundell podcast, Antoine van der Lee, creator of SwiftLee, joins John Sundell. They discuss the new language features that are being introduced as part of Swift 5.5 — from the brand-new concurrency system, to convenience features and various improvements.
News and community
It turns out that Xcode has documentation for its minimum requirements and supported SDKs.
Proposals in review
A package registry is responsible for determining which package releases are made available to a consumer.
Currently, the availability of a package release is determined by an out-of-band process. For example, a registry may consult an index of public Swift packages and make releases available for each tag with a valid version number.
Having a standard endpoint for publishing a new release to a package registry would empower maintainers to distribute their software and promote interoperability across service providers.
In a protocol, all fields (properties and methods) will get the access visibility of the conforming type. For instance, conforming to a protocol with a public type will prompt all of its requirements to be public.
- The main function should run synchronously up to the first suspension point.
- The main function should be run on the main actor
- MainActor should provide a user-specifiable alternative to the default runloop behaviour.
- Make the main task pull the priority from
getCurrentThreadPriorityinstead of a hard-coded
Anders Bertelrud proposed amending to SE-0303: Plugin API to Use
@main for Plugin Entry Point.
I’d like to propose amending SE-0303 so that SwiftPM plugins use
@maininstead of top-level code for entry points. While it’s a little more verbose, this would allow customized entry points for each kind of plugin, and would also make it clearer what the inputs and expected outputs of each plugin are.
SE-0302 introduced the
Sendableprotocol, which is used to indicate which types have values that can safely be copied across actors or, more generally, into any context where a copy of the value might be used concurrently with the original. Applied uniformly to all Swift code,
Sendablechecking eliminates a large class of data races caused by shared mutable state. Swift 5.5 does not perform complete checking for
Sendablebecause doing so resulted in so many compiler errors and diagnostics that it undermined the usability of the feature.
I think we can stage in
Sendablechecking to improve data-race safety over time without. We propose two principles to guide the design of staged
- Incremental adoption of concurrency should introduce incrementally more
Sendableproblems outside the user’s module should not block progress nor produce an undue annotation burden.
The module would re-export the correct module that contains the POSIX or POSIX-like C standard library for the current platform, if any; it would not be imported by default, but would allow “reasonably cross-platform” code to avoid using lengthy
#if canImport(…)chains to gain access to all possible stdlibs, given that they have different names on different OSs.
For example, the module may be named
As part of our efforts to improve the ergonomics of the generics system, as well as providing better support for abstractions that use tuples, I wanted to approach y’all with a sketch for the surface syntax and preliminary semantics. Because this is a large topic area with a lot of impacts on the direction of both the language and later proposals, your feedback is critical at this stage for shaping the direction this feature set is taken in.
I want to thank (in no particular order) Alejandro Alonso, Doug Gregor, and Slava Pestov for shaping my thinking on this subject, and for advancing a lot of the foundations here.
You can find the link to the text of the pitch here TypeSequences.md · GitHub