Is adding a `Sendable` requirement a breaking change?

[haikuty]

Yep.
I brought up the warnings that can’t be disabled issue ( SE-0337: Incremental Migration to Concurrency Checking - #6 by haikuty ) back when the incremental migration to concurrency plan was being proposed and being discussed and got the following reply:

@Douglas_Gregor

Now, this isn't the only suppression mechanism. One is permitted to write an @unchecked Sendable conformance for a type from another module; that suppresses the warning because the type is now Sendable. Teams that use Swift 6 with warnings-as-errors will need to maintain these @unchecked Sendable conformances, which seems acceptable because it is explicit.

Curious if this technique work in the situation you describe to allow reenabling warnings as errors? (Sorry I’m not up to speed on this stuff; I’ve been out for an extended period).