Reviews are an important part of the Swift evolution process. All review feedback should be either on this forum thread or, if you would like to keep your feedback private, directly to the review manager via the forum messaging feature. When contacting the review manager directly, please keep the proposal link at the top of the message.
Try it out
You can try out this feature in a nightly toolchain by enabling the experimental feature TildeSendable.
What goes into a review?
The goal of the review process is to improve the proposal under review through constructive criticism and, eventually, determine the direction of Swift. When writing your review, here are some questions you might want to answer in your review:
What is your evaluation of the proposal?
Is the problem being addressed significant enough to warrant a change to Swift?
Does this proposal fit well with the feel and direction of Swift?
If you have used other languages or libraries with a similar feature, how do you feel that this proposal compares to those?
How much effort did you put into your review? A glance, a quick reading, or an in-depth study?
More information about the Swift evolution process is available here.
Suppression must be declared on the struct, enum or class type declaration itself, not on an extension, because otherwise there is a risk of changing the meaning of the existing code:
extension Test: ~Sendable {} // Error!
How does one restrict the effects of ~Sendable to certain platforms without an extension? My natural inclination would be to do this:
@available(toasterOS 1.0, rocketShipOS 2.0, *)
open class ParentClass {
// ParentClass has been available on toasterOS since 1.0 and rocketShipOS 2.0.
// It was introduced without sendability auditing.
}
@available(toasterOS 4.0, *)
extension ParentClass: ~Sendable {
// ParentClass has only undergone sendability audit for toasterOS as of toasterOS 4.0.
// It has not undergone auditing on rocketShipOS yet.
}
I’m in favor of this proposal and am excited to adopt this feature in a number of places. We’d really like to use -require-explicit-sendable in Foundation to prevent accidentally shipping an API without Sendable auditing, but it has not been possible without the ability to express ~Sendable. We currently express this via code comments in swift-corelibs-foundation, but codifying it in the interface is definitely an improvement.
As a future direction, this will also be quite helpful with sendable annotations for code imported from Objective-C headers. The current NS_HEADER_AUDIT macros mark all declarations as explicitly non-Sendable (as if there were an unavailable extension) without a way to suppress the implicit unavailable conformance. Allowing a ~Sendable annotation on an imported Objective-C API would allow for declaring Objective-C classes as non-Sendable while allowing Sendable subclasses while using the standard recommended NS_HEADER_AUDIT macros.
I think what you want to do is to mark your type as conditionally Sendable on platforms you want and that would make it non-Sendable everywhere else without requiring you to use ~Sendable.
Doesn’t marking the main declaration as ~Sendable implicitly indicate that sendability has been reviewed for all platforms that the declaration is @available() on?
// Actors are always `Sendable`.
actor A: ~Sendable { // error: cannot both conform to and suppress conformance to 'Sendable'
}
It's not feedback to block this proposal but a potential thought experiment as an "alternative considered" might be if there is any very niche application here where an actor might need to only be conditionally Sendable. And then have a quick discussion about why continuing to enforce actor types must always be Sendable is the right thing to do.
This is great overall and much needed! In server ecosystem I have a few types I'd mark this way but we've been getting away with unavailable Sendable for now, this is much preferable though.
I've read through in detail and don't see any major problems with the semantics as proposed
I think my only nitpick is that I feel <T: ~Sendable>should be allowed (even though it's basically a no-op) for consistency's sake. But I wouldn't get out my placard and crayons over it.
