While this is primarily aimed at developers of server libraries, such that we can ensure a smooth transition towards swifts concurrency model, it likely has some interesting bits for everyone
You may also be interested in the following sources:
I'm sure there are already many more examples of Sendable adoption in the server. We hope the guide will be a helpful, and growing resource, to share patterns and plans about how to prepare and get to Swift 6's full Sendability checking model.
Please feel free to send in PRs to the guide, and/or ask questions there or on there forums here!
Special thanks to @fabianfett, @lukasa and all the reviewers of the guide during its draft phase!
Should the guide be updated to reflect the back deployment OS targets with Xcode 13.2? Once that ships this document may be confusing when they don't match.
I really like the intent of this document but have concerns about its impact. Server side Swift will generally execute on more current versions of the operating system than can be expected for clients. As a result, server side code may rely on features present in the most recent versions of Swift. We are now about six months past WWDC and compliance with even the most basic guideline is spotty:
Firstly, existing libraries should strive to add async functions where possible to their user-facing “surface” APIs in addition to existing *Future based APIs wherever possible.
Rather than call out specific libraries, I am curious if the SSWG has target dates by which current projects must implement concurrency or other features to remain in good standing. The Incubation Process document requires concurrency in the 'Minimal Requirements' and allows the SSWG to "demote, archive, or remove projects that no longer fulfill minimal requirements".
Speaking only for myself here, not on behalf of SSWG:
While WWDC was ~6 months ago I'm not sure that is fair to cite; Swift 5.5 only went GA 2 months ago. Additionally, the minimum macOS version required to use structured concurrency features was only released 1 month ago, and these guidelines only published 3 weeks ago.
Given all this, in my opinion it is very reasonable that many libraries are yet to release new async APIs as developers may have wished to wait for both stability of new features and guidance from the SSWG.
Personally, I've been in the process of incorporating structured concurrency in MongoSwift recently, which has been a non-trivial amount of work given our extensive API surface, design questions around e.g. doing async resource cleanup on detached tasks and which methods make sense to still have around in an async API, a few Swift bugs I've run into, getting CI setup for macOS with concurrency available, etc.
I'm also very eager to see libraries adopt structured concurrency and enable their users to do the same, but as a maintainer myself working to deliver these changes as quickly as I can, I would encourage some patience. I'm also fortunate in that I'm doing this work as my job; a number of these libraries are maintained by community members in their free time who may have far less hours to spend on this than I have had.
If there's a particular library you're interested in seeing structured concurrency adoption in, I would suggest filing an issue/reaching out to the maintainers to get more information on their plans and expected timeline, and perhaps if you have availability to see if you can help contribute such support.
I'd also point out that NIO's EventLoopFuture.get() method as described in the guide may be useful for you to use directly as a stopgap in some cases, if you need an async version of a method that doesn't have one yet.
I don't believe this is something we've discussed, but I will add it to the agenda for our next meeting to consider if/how structured concurrency specifically should be incorporated into the requirements and if we have any expected timeline for libraries at various stages of maturity to do so.
I think the reference to concurrency currently in the guidelines predates the introduction of structured concurrency and was referring to incorporating the previously recommended paradigms e.g. EventLoopFutures.
