-
Implementation: implementation, Interaction with ObjC
-
Experimental Feature Flag:
TildeSendable
Introduction
This pitch introduces ~Sendable conformance syntax to explicitly suppress a conformance to Sendable, which would prevent automatic Sendable inference on types, and provide an alternative way to mark types as non-Sendable without inheritance impact.
Motivation
When encountering a public type that doesn't explicitly conform to Sendable, it's difficult to determine the intent. It can be unclear whether the type should have an explicit Sendable conformance that hasn't been added yet, or whether it's deliberately non-Sendable. Making this determination requires understanding how the type's storage is structured and whether access to shared state is protected by a synchronization mechanism - implementation details which may not be accessible from outside the library.
There are also situations when a class is not Sendable but some of its subclasses are. There is currently a way to expression that a type does not conform to a Sendable protocol:
class Base {
// ...
}
@available(*, unavailable)
extension Base: Sendable {
}
Like all other conformances, an unavailable conformance to Sendable is inherited by subclasses. An unavailable conformance means that the type never conforms to Sendable, including all subclasses. Attempting to declare a thread-safe subclass ThreadSafe:
Attempting to declare a thread-safe subclass ThreadSafe:
final class ThreadSafe: Base, @unchecked Sendable {
// ...
}
is not possible and results in the following compiler warning:
warning: conformance of 'ThreadSafe' to protocol 'Sendable' is already unavailable
because unavailable conformance to Sendable is inherited by the subclasses.
This third state of a class not having a conformance to Sendable because subclasses may or may not conform to Sendable is not explicitly expressible in the language. Having an explicit spelling is important for library authors doing a comprehensive Sendable audit of their public API surface, and for communicating to clients that the lack of Sendable conformance is deliberate, while preserving the ability to add @unchecked Sendable conformances in subclasses.
Proposed Solution
Introduce ~Sendable conformance syntax that explicitly suppresses Sendable:
// This type will never be inferred as Sendable because though it could be inferred as such.
struct MyType: ~Sendable {
let value: Int
}
This syntax is only applicable to types because other declarations like generic parameters are already effectively ~Sendable by default until they have an explicit Sendable requirement.
Detailed Design
The ~Sendable conformance uses the tilde (~) prefix to indicate suppression similar to ~Copyable, ~Escapable, and ~BitwiseCopyable:
// Suppress Sendable inference
struct NotSendableType: ~Sendable {
let data: String
}
// Can be combined with other conformances
struct MyType: Equatable, ~Sendable {
let id: UUID
}
// Works with classes
class MyClass: ~Sendable {
private let data = 0
}
Just like with unavailable extensions, types with ~Sendable conformances cannot satisfy Sendable requirements:
func processData<T: Sendable>(_ data: T) { }
struct NotSendable: ~Sendable {
let value: Int
}
processData(NotSendable(value: 42)) // error: type 'NotSendable' does not conform to the 'Sendable' protocol
But, unlike unavailable extensions, ~Sendable conformances do not affect subclasses:
class A: ~Sendable {
}
final class B: A, @unchecked Sendable {
}
func takesSendable<T: Sendable>(_: T) {
}
takesSendable(B()) // Ok!
Attempting to use ~Sendable as a generic requirement results in a compile-time error:
func test<T: ~Sendable>(_: T) {} // error: conformance to 'Sendable' can only be suppressed on structs, classes, and enums
Attempting to explicitly conform (both conditionally and unconditionally) to both Sendable and ~Sendable results in a compile-time error:
struct Container<T>: ~Sendable {
let value: T
}
extension Container: Sendable {} // error: cannot both conform to and suppress conformance to 'Sendable'
extension Container: Sendable where T: Sendable {} // error: cannot both conform to and suppress conformance to 'Sendable'
The Swift compiler provides a way to audit Sendability of public types. The current way to do this is by enabling the -require-explicit-sendable flag to produce a warning for every public type without explicit Sendable conformance (or an unavailable extension). This flag now supports ~Sendable and has been turned into a diagnostic group that is disabled by default - ExplicitSendable, and can be enabled by -Wwarning ExplicitSendable.
Source Compatibility
This proposal is purely additive and maintains full source compatibility with existing code:
- Existing code continues to work unchanged
- No existing
Sendableinference behavior is modified - Only adds new opt-in functionality
Effect on ABI Stability
~Sendable conformance is a compile-time feature and has no ABI impact:
- No runtime representation
- No effect on existing compiled code
Effect on API Resilience
The ~Sendable annotation affects API contracts:
- Public API: Adding
~Sendableto a public type does not impact source compatibility becauseSendableinference does not apply to public types. Changing aSendableconformance to~Sendableis a source breaking change.
Alternatives Considered
@nonSendable Attribute
@nonSendable
struct MyType {
let value: Int
}
Protocol conformance is more ergonomic considering the inverse case, and it follows the existing convention of conformance suppression to other marker protocols.
Acknowledgements
Thank you to Holly Borla for the discussion and editorial help.
