I actually read the mutex proposal, but before transferring was changed to sendable (at least in 0433 itself), so I did not notice it then. I actually thought it to be very reasonable and useful (even though I personally have no use-case for it atm), but did not feel confident enough in actually voting.
But I can gladly provide a small example, pretending to be a novice and not knowing what I know from this entire discussion: Let's assume I have some very simple reference type I want to protect with a mutex:
class PleaseProtecc: ~Copyable {
// let's for a moment ignore that a novice probably won't get ~Copyable either...
var maybeARawFileHandle: Int32
}
Let's assume I am already using this elsewhere in my app and the strict concurrency diagnostics successfully prevented me from passing this around isolation regions because it does not conform Sendable. Perhaps I, although I am a novice, even know that whatever I do with it (let's say some socket I/O) is not "thread-safe", but I don't know exactly how I could make it thread-safe (because low-level C, buffers, whatever). I come across the Mutex API precisely because I am looking for something to protect my instance with.
But then, with autocompletion, I see:
public init(_ state: sendable consuming State)
Even if I just complete the snippet and do
let myMutex = Mutex(myPleaseProteccInstance)
and it doesn't show me an error or warning, I am most likely very hesitant that this is okay.
I might be under the impression that the sendable tells me that whatever I pass must conform to the Sendable protocol, which I tried to avoid having to conform to in the first place.
Now, taking the novice hat off, I know that this cannot be what is meant, as a required protocol conformance would be expressed via generics in the Mutex definition (which just requires State to be ~Copyable and not explicitly Sendable), but that's beside the point.
All in all, I am not completely against it, but a difference between this point of friction and others, language-wise, is that with Sendable we have taught people that the emphasis is explicitly not on the "you can't use stuff you have sent away", but sendable is precisely that.
That's different from, e.g. "not adopting BitwiseCopyable does not imply NotBitwiseCopyable problem. Here we're relying on two different aspects of the original (English) semantic of the word "sendable".
@taylorswift: Yes, that was one of my major issues.
And @sliemeobn: You are right, I am also not a fan of "over-protecting" any newcomers, complex things are complex and falling flat on your face with those once is actually often better in the long run, but in this case we should also not not regard it. We are using the same word.
I try to rephrase it better: "Sendable" in an English meaning would imply two things at once: A thing that can be "put from one place to another" (a form of sharing) AND, once that actually happens, "you cannot use it at the first place anymore" (relenting control).
Sendable focuses on the first part (we can still use a Sendable reference in the isolation region we "sent" it from), sendable on the second (we cannot).
).