Assert negative trait bounds

[ecstatic-morse]

To my knowledge, assert_impl! cannot assert that a given type T satisfies, for example, T: !Send.

[nvzqz]

This has been mentioned previously at #2 (comment). I agree that this would be a useful feature; I just haven't thought of a way it can be implemented.

[ecstatic-morse]

So, I wasn't aware that the negative trait bound syntax was only available on nightly (it appears in the docs for Rc<T>), but I did come up with a way to do assert_not_impl! with a few caveats:

struct Success;
#[derive(Clone)]
struct Negative;

trait NotClone {}
impl<T> NotClone for T where T: Clone {}

impl NotClone for Success {}  // No problem!
// impl NotClone for Failure {} // Causes a compiler error

This (ab)uses a blanket impl to cause types which implement a trait to fail to compile. Unfortunately, it only works for types which are defined in the crate in which the assertion is called. This seems like the normal use case for static_assertions. Also, it does not currently work for auto traits (Send and Sync). I filed issue 50551 to track this.

[nvzqz]

Yeah, it seems that approach isn't viable as of yet. The compiler still has some bugs that it needs to iron out. Here are some other failed attempts.

[ecstatic-morse]

Ah, it seems I'm not the first person to wander down this path. Do you consider the restriction that either the type or the trait must be defined in the same crate to be a deal breaker? It seems like that condition would be satisfied for most uses of assert_not_impl!.

[nvzqz]

I'd like to see some issues—such as the compiler suggesting that [u8], an unsized type, can somehow implement Copy—ironed out before committing to this sort of implementation. Obvious assertions failing when they should be passing makes for very poor library design, in my opinion.

[ecstatic-morse]

Oof, yeah, I agree. The error messages are pretty tough as well. Thanks for your time!

[HeroicKatora]

I've had a new idea for this: #17. Ambiguity in name resolution can also trigger a compilation error, thus we introduce two competing traits with the same method. One of the traits is always implemented while the other is only implemented when the trait bounds are met. When the type implements all the supplied trait the compiler can no longer resolve the method name to a single trait and compilation fails. When the trait bound is not met, the compilation succeeds. To ensure that no other trait may interfere with name resolution we include a single parameter that is of a local type, effectively sealing the method signature.

[nvzqz]

This is resolved by #17, which was just merged.