Note that incorrect conformance to [ActorSendable] can introduce bugs in your program (just as an incorrect implementation of Hashable can break invariants). For example, it would be incorrect (and very unwise!) to add to your codebase, because it results in a shared reference to mutable state:
If you want to make sure your Hashable implementation is correct, you have to look only at the Equatable and Hashable implementation. If you want to make sure your implementation of ActorSendable is correct, you have to look at all the properties and all the methods of your type, including the ones in extensions and subclasses, and if your type is open/public it includes extensions and subclasses that aren't written by you. Much harder to do.
That's because ActorSendable is not about what the the type can do, it's about what a type cannot do, which is the opposite of all the protocols in the standard library. It reminds me of negative generic constraints.
Auto-synthesized Struct/Enum ValueSemantic Conformances
What if my type isn't ValueSemantic, even though all the stored properties are? Would there be a way to opt-out from the conformance?
future work
// Capturing a ‘searchName’ string is ok, because it is ActorSendable.
list = await contactList.filteredElements { $0.firstName==searchName }
That closure captures a variable, not the string. Because of that it's referencey, so shouldn't be ActorSendable (unless searchName is a let)
struct S {
var firstName = "World"
}
var searchName = "Hello"
let f: (S) -> Bool = { $0.firstName==searchName}
print(f(S())) // false
searchName = "World"
print(f(S())) // true
If you want to capture the string, you have to use { [searchName] in $0.firstName==searchName }