WWDC21 is just around the corner, and I believe we will have many significant updates then.

My favourite news piece in the last two weeks is the Swift Mentorship Program announcement. Mentoring and discovering how I can help others grow in their careers is very demanding but rewarding. I wish I had someone who could help me early in my career. So I encourage you to use this opportunity to get involved. Thank you to everyone who is making this possible.

Now let’s check out what’s happened in the last two weeks!

News and community

The Diversity in Swift workgroup announced the Swift Mentorship Program.

Leo G Dion wrote a great article: Swift Packages – Dependency Management of the Future.

Andy Ibanez explored Swift’s print, in depth.

Ole Begemann wrote an article about how OrderedSet works.

Commits and pull requests

Chris Adamson merged a pull request that provides documentation comments for AsyncSequence and related types.

Jiri Dutkevic merged a pull request that removes the UseSwiftCall/enable_swiftcall frontend option because it wasn’t used and resolves SR-14453.

fredriss merged a pull request that adds a unique Task ID to AsyncTask.

David Smith merged a pull request that adds a missing _Concurrency dependency to the Dispatch overlay.

Accepted proposals

SE-0313 Improved control over actor isolation was accepted with revisions.

The core team (with discussion with the proposal authors) has decided to accept a subset of the proposal. The revised (and accepted) proposal has the following parts removed:

  • Support for multiple isolated parameters
  • The proposed changes for closure isolation control

The removed parts, which were the most controversial sources in the review discussion, can be revisited in a future Swift Evolution proposal.

The review discussion also discussed the tradeoffs between a syntax-driven versus type-driven approach. The core team discussed the tradeoffs of the two methods and observed that a type-based approach would (by design) pervade the type system and potentially result in a more complicated system. The core team thus preferred the syntax-based approach in the proposal.

Returned proposals

SE-0292 has been returned for revision.

Before diving into further details, the core team would like to acknowledge it took an unusual long time to provide feedback to this proposal given Swift’s concurrency model proposals, which taken precedence over other proposals including SE-0292. The core team would like to thank the authors of SE-0292 for their patience and reiterate the importance of SE-0292, especially given its potential role in defining how Swift module disambiguation could work.

Most reviewers, as well as the core team, felt the 2nd iteration made significant progress towards acceptance. With that said, the core team would like to see the following points addressed before putting the proposal into a narrowly scoped third review.

Proposals in review

SE-0314: AsyncStream and AsyncThrowingStream is under review.

The continuation types added in SE-0300 act as adaptors for synchronous code that signals completion by calling a delegate method or callback function. For code that instead yields multiple values over time, this proposal adds new types to support implementing an AsyncSequence interface.

Swift-evolution threads:

SE-0306: Actors and nonisolated let amendment is under a review.

This amendment is motivated by having more hands-on experience incrementally adopting actors into an existing app. Immutable object state is very common, and as originally accepted, the proposal requires even immutable let properties in actors to be treated as actor-isolated unless explicitly marked isolated. The proposal authors feel that in practice this creates too heavy of an annotation burden when turning existing code into actor code, since every immutable value must either be marked nonisolated or await-ed everywhere. There were however legitimate concerns about library evolution in the original review if public lets would be implicitly exported as non-isolated by default, since that would limit the library author’s ability to turn the declarations into locally-mutable state or computed properties with isolated computation in the future. This amendment seeks to balance the competing considerations by allowing let properties on actors to be accessed without isolation locally within a module, but not across modules unless the declaration is explicitly nonisolated.

Swift Forums

Craig Hockenberry pitched an idea to fix if let syntax.

Kaitlin Mahar updated us about Swift on the Server Workgroup April 28, 2021 meeting notes.

Doug Gregor informed that he updated the revision of the global actors proposal.

Changes from the first pitch include:

  • Clarify that the types of global-actor-qualified functions are global-actor-qualified.
  • State that global-actor-qualified types are Sendable
  • Expand on the implicit conversion rules for function types
  • Require global and static variables to be immutable & non-isolated or global-actor-qualified.
  • Describe the relationship between global actors and instance actors
  • Update inference rules for global actors

Konrad Malawski updated the async let proposal with the latest semantics and spelling details.

This is the first pitch of the feature as a stand-alone thing, it was previously pitched as part of structured concurrency pitch #1 3, and pitch #2 and was separated out later on as it’s a feature large enough to deserve its own discussion.

Changes since the original pitch are mostly focused around additional discussion and details around exact semantics of the feature, e.g., we added:

  • longer discussion of throwing semantics
    • this is an area we’d welcome discussion of. I.e. currently if an async let has a throwing initialiser, and is not awaited explicitly, the task is awaited on implicitly but the thrown error is silently dropped. This is equivalent to TaskGroup semantics and in line with “since you didn’t await on it, you clearly don’t care about it” however it may have some tricky implications.
  • more details about cancellation handling

Igor Makarov pitched an idea to allow calling type members from instance members without Self..

Following up on the previous discussion, I wanted to refine my suggestion with the one Svein proposed.

Make the prefix Self. non-required when calling a type member (static or class) from an instance member. This can apply to botb methods and properties.

Adam Fowler explained how Swift SDK for AWS works.

Soto is a third-party Swift SDK for Amazon Web Services (AWS). The library provides access to all AWS services and works on Linux, macOS, and iOS.

Soto is heavily integrated with a number of Swift on Server packages including AsyncHTTPClient, SwiftNIO, Logging, Metrics and is primarily targeted for Swift on Server. All the API calls are designed to be called in an asynchronous manner to avoid blocking your current thread.

Even though it isn’t the primary target we have still put in a fair amount of work to ensure the library works on iOS and will continue to ensure this is the case.

Richard Venable pitched an idea about enum case inferencing.

I was reading the discussion on Let’s fix if let syntax. It’s a good discussion, but it overlooks how weird Swift is to encourage us to create variables that replace existing variables but with a different type (optional type replaced with non-optional type). let x = x is a weird pattern, but we are all just accustomed to it.

Meanwhile, the proposal to just use if x != nil { } is not getting enough attention. There was an objection saying “I find it really weird that merely performing a comparison would change the type of a variable from optional to non-optional.” But what if we weren’t changing the type of a variable? What if it is the same variable - the Swift compiler just infers what we want to do with it based on prior knowledge.

Konrad Malawski informed about 5 accepted projects for this year’s Swift in GSoC.

  • SwiftPM support for Swift scripts
  • Inlay type hints for SourceKit-LSP
  • Alive2 for SIL
  • A “Bite-Sized” BitArray
  • Shared Storage for Property Wrappers

Details about the accepted projects can be found here: https://summerofcode.withgoogle.com/organizations/5050498865954816/#projects

Finally

What is the real age of Swift?