cc @arthurprs

Cargo expects features to be additive. This means that enabling features must never break code. It must only allow more code. By making the deadlock detection feature disable the Send impl for MutexGuard you are breaking code.

While that's the expectation, there are lots and lots of examples of mutually exclusive features out there. But that's just my opinion.

In those cases it is often choosing between two or more backends for a crate. This means that 1. the target executable is likely the one enabling the feature flag and 2. you can't accidentally depend on a feature flag being disabled, as you have to explicitly enable one feature flag to break another one. You can't just have a crate compiling with no feature flags enabled at all and then break when you enable one feature flag.

A better alternative than simply breaking code when enabling the deadlock_detection feature flag would be to add a new sendable_guard feature flag to enable this and add a compile_error! when both feature flags are enabled. While this does still violate the additive assumption, this does makes it a lot harder to accidentally depend on the Sendness of lock guards.

@bjorn3 That sounds like a great idea!