Given that type UUID is a struct I thought it would be Sendable
. But the compiler generates a warning:
struct S: Sendable {
var int: Int
var id: UUID // <-- Stored property 'id' of 'Sendable'-conforming struct 'S' has non-sendable type 'UUID'
}
Given that type UUID is a struct I thought it would be Sendable
. But the compiler generates a warning:
struct S: Sendable {
var int: Int
var id: UUID // <-- Stored property 'id' of 'Sendable'-conforming struct 'S' has non-sendable type 'UUID'
}
UUID does not conform to Sendable (even though it is a struct, but some of its components may be mutable ?) Conforms to:
Hence, S does not conform either.
See example in Proposal: SE-0302 https://github.com/apple/swift-evolution/blob/main/proposals/0302-concurrent-value-and-concurrent-closures.md
// error: MyNSPerson cannot conform to Sendable due to NSMutableString member.
// note: add '@unchecked' if you know what you're doing.
struct MyNSPerson : Sendable {
var name: NSMutableString
var age: Int
}
So, I want to draw your attention to this quote from Concurrency in Swift 5 and 6:
This allows
Sendable
conformances to be built up throughout the ecosystem without blocking incremental adoption on a bottom-up process.
Adding Sendable
conformances to library types — both built-in stuff like UUID
and third-party libraries — is part of that “incremental adoption” process.
Share and Enjoy
—
Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@" + "apple.com"
To bump an old thread... UUID is now Sendable!