Issue #195 07 Oct 2021
Written by: Kristaps Grinbergs
We’re starting today’s newsletter with some hiring news from Apple: they are looking for paid interns for their language, compiler and debugger teams. Even if you don’t have experience in the specific field, interested students are encouraged to apply anyway. If you’d like to understand better how internships work, have a look at this insightful article about Amritpan Kaur’s path through Compiler Development and Language Design.
There have been some really nice improvements made to Swift.org recently, including support for dark mode. For those of you using dark mode on iOS, the website will automatically switch modes to match. I hope you’re enjoying this feature as much as I am.
As always, I want to express our appreciation for the support from our sponsors. Without you this newsletter wouldn’t exist, so thank you very much. If anyone else is interested in sponsorship, please kindly get in touch. More information on how you could participate in our project can be found here.
From October 18th to 24th you can join a free practical crash course for iOS devs who want to become complete senior developers.
SR-15271 [Compiler] Improve Codable Diagnostics When
CodingKeysDo Not Match Properties
News and community
Commits and pull requests
Proposals in review
MultipartKit offers both low level parsing and serializing of Multipart data as well as high level Codable support for encoding and decoding Multipart form data.
I just filed issue #45, asking
ManagedAtomicand friends to be marked
Sendable, reflecting that they are safe to transfer across concurrency domains.
The proposed solution to some of the problems described in this proposal are currently reflected in Swift 5.5 through a warning, but it’s important to review these changes for Swift 6. In addition, this proposal adds extra capabilities for the
deinitof MainActor-isolated class, to make them easier and safer to write. I’ll paste the entire proposal below, but for the most up-to-date write-up, go here.
I’ve discovered several stack corruption bugs related to
awaitwhich can be reproduced in simple test programs compiled with recent nightly toolchains. i have confirmed that
two threefour of these bugs are present in the 5.5-RELEASE toolchain.
A couple weeks ago, @Douglas_Gregor pitched some changes which tried to tackle some of the problems involved in adopting
Sendablechecking in a module when some of your clients or dependencies may not have updated yet. I had some concerns about how that pitch’s approach might break or hide bugs when modules were eventually updated, as well as with how Objective-C libraries would be able to control the sendability of their types.
The arrival of Swift 6 means a chance for “regretting” some language designs with API breakage — after 3 years which is fairly a long time for Swift and the Swift community. With the Swift 3.2 and Swift 4.2 effort, transition to a breaking Swift release has proved to be a lot smoother.
I would suggest we pick up some of the deferred breaking pitches, which intended to eliminate inconsistency within the language. These ideas have already received positive feedbacks from the community, and yet didn’t make their ways into reality.
The concepts of time can be broken down into three distinct parts: an item to provide a concept of now plus a way to wake up after a given point in time, a concept of a point in time, and a concept of a measurement in time. These three items are respectively a clock, an instant and a duration. The measurement of time can be used for many types of APIs, all the way from the high levels of a concept of a timeout on a network connection, to the amount of time to sleep a task. Currently the APIs that take measurement of time types take
DispatchTimeInterval, and even types like
String processing is hard and the current affordances provided by the Swift Standard Library are underpowered. We propose adding two new declarative string processing APIs—a familiar
Regexliteral and a more powerful
Patternresult builder—to help make Swift string processing fast and easy.
This is a large feature that will ultimately be divided into multiple Swift Evolution proposals. This initial pitch is intended to prompt discussion about the high level direction and to introduce the key prongs of the feature and their relationship to one another.
for those who don’t follow the Development topic, @mickeyl, @timdecode, and i have recently uncovered an alarming number of highly dangerous stack corruption bugs in the Swift 5.5 release toolchain.
setting aside the technical aspects of the stack corruption issues in Swift 5.5, which are detailed in the corresponding thread, i would like to kickoff discussions on whether it would be valuable for us to adopt some form of the concept of a “Long-Term Support” (LTS) release 8 in our release cycle, much like Ubuntu has been doing for some time.
SE-0303 introduced SwiftPM plugins, focusing in particular on build tool plugins (especially those that generate source code). To keep that proposal bounded, the type and amount of information available to a plugin was geared toward the task of generating build commands.
Before starting to consider new kinds of plugins, it seems prudent to expand the information available to plugins of all kinds. Future proposals might add specific APIs for particular kinds of plugins, but before that, it seems that a good starting point would be to give all plugins access to a distilled form of the package graph that SwiftPM already has internally. This should allow a wide latitude in terms of what any particular plugin wants to do.
I’d like to pitch a draft proposal for extending the API available to SwiftPM plugins, and would love to hear what everyone thinks. There’s an implementation in a PR in the SwiftPM repository.
Guillaume Lessard pitched a proposal to expand usability of
withMemoryRebound(to:capacity:_ body:)executes a closure while temporarily binding a range of memory to a different type than the callee is bound to.
We propose to lift some notable limitations of
withMemoryReboundand enable rebinding to a larger set of types, as well as rebinding from raw memory pointers and buffers.
I want to propose such a type here: a branching resource.
A BranchingResource would be a type with a generic parameter for the payload it carries (ie the resource). The resource would begin with a single branch, called “main” or “trunk” or “truth”. The app could add as many auxiliary, named branches as it likes.
I propose to improve inference behavior of multi-statement closures by enabling parameter and result type inference from the closure body. This will make type inference less surprising for developers, and remove the existing behavior cliff where adding one more expression or statement to a closure could result in a compilation failure.