Tracking issue for negative impls

[nikomatsakis]

Generalized negative impls were introduced in https://github.com/rust-lang/rust/pull/68004. They were split out from "opt-in builtin traits" (https://github.com/rust-lang/rust/issues/13231).

Work in progress

This issue was added in advance of #68004 landed so that I could reference it from within the code. It will be closed if we opt not to go this direction. A writeup of the general feature is available in this hackmd, but it will need to be turned into a proper RFC before this can truly advance.

Current plans

• [ ] Forbid conditional negative impls or negative impls for traits with more than one type parameter (https://github.com/rust-lang/rust/issues/79098)
• [ ] Forbid !Drop (negative impls of Drop)

Unresolved questions to be addressed through design process

• What should the WF requirements be? (Context)
• Should we permit combining default + negative impls like default impl !Trait for Type { }? (Context)

[pirocks]

Odd possibly off topic question about this. The following compiles:

#![feature(negative_impls)]

pub struct Test{

}

impl !Drop for Test {}

fn foo(){
    drop(Test{})
}

Should it?

[Allen-Webb]

Odd possibly off topic question about this. The following compiles:

#![feature(negative_impls)]

pub struct Test{

}

impl !Drop for Test {}

fn foo(){
    drop(Test{})
}

Should it?

I would say no, because if you wanted to shift the error to runtime you could implement Drop as:

pub struct Test{

}

impl Drop for Test {
    fn drop() {
        panic!("Do not drop Test.")
    }
}

I generally like to catch anything at compile time that can be caught at compile time.

[gThorondorsen]

According to the documentation

This function is not magic; it is literally defined as

pub fn drop<T>(_x: T) { }

As a trait bound, T: Drop means that the type has defined a custom Drop::drop method, nothing more (see the warn-by-default drop_bounds lint). It does not mean that T has non-trivial drop glue (e.g. String: Drop does not hold). Conversely, T: !Drop only says that writing impl Drop for T { … } in the future is a breaking change, it does not imply anything about T's drop glue and definitely does not mean that values of type T cannot be dropped (plenty of people have tried to design such a feature for Rust with no success so far).

(If you did not already know, drop glue is the term for all the code that std::mem::drop(…) expands to, recursively gathering all Drop::drop methods of the type, its fields, the fields of those fields, and so on.)

Yes, the Drop trait is very counter-intuitive. I suggest extending drop_bounds to cover !Drop as well. Maybe even mentioning !Drop at all should be a hard error for now (neither impls nor bounds make sense IMO). Can @nikomatsakis or anyone else add this concern to the unresolved questions section in the description?

[rMazeiks]

Not sure if this is the right place to report a bug with the current nightly implementation, but a negative implementation and its converse seem to "cancel each other out".

For example:

trait A {}
trait B {}

// logically equivalent negative impls
impl<T: A> !B for T {}
impl<T: B> !A for T {}

// this should not be possible, but compiles:
impl A for () {}
impl B for () {}

The above compiles without errors on nightly, though it shouldn't. Removing one of the negative impls fixes the issue and results in an error as expected.

[JohnScience]

Allowing negative trait bounds would make my code much better by allowing to express di- and poly-chotomy.

In Rust 1.57.0 the following doesn't compile:

#![feature(negative_impls)]

trait IntSubset {}

impl <T> IntSubset for T where T: FixedSizeIntSubset + !ArbitrarySizeIntSubset {}
impl <T> IntSubset for T where T: !FixedSizeIntSubset + ArbitrarySizeIntSubset {}

trait FixedSizeIntSubset {}

impl<T: FixedSizeIntSubset> !ArbitrarySizeIntSubset for T {}

trait ArbitrarySizeIntSubset {}

impl<T: ArbitrarySizeIntSubset> !FixedSizeIntSubset for T {}

[mwerezak]

Coming here from a compiler error, how do I "use marker types" to indicate a struct is not Send on stable Rust? I don't see any "PhantomUnsend" or similar anywhere in std.

error[E0658]: negative trait bounds are not yet fully implemented; use marker types for now

[rMazeiks]

@mwerezak I think I've seen PhantomData<*mut ()>. If I understand correctly, *mut () is not Send, so neither is the enclosing PhantomData nor your struct. (Did not test)

PhantomUnsend might be a good alias/newtype for better readability – I had no idea what PhantomData<*mut ()> meant at first :D

[mwerezak]

@rMazeiks Thanks, I wouldn't have known really what type would be the appropriate choice to use with PhantomData for this.

A PhantomUnsend sounds like a good idea.

[nikomatsakis]

I think we should just rule out !Drop -- drop is a very special trait.

[dhardy]

Can we add "negative super traits" to the unwritten RFC? That is,

pub trait Foo {}

pub trait Bar: !Foo {}

// We now know that the two traits are exclusive, thus can write:
trait X {}
impl<T: Foo> X for T {}
impl<T: Bar> X for T {}

Quote from the Hackmd:

This implies you cannot add a negative impl for types defined in upstream crates and so forth.

Negative super traits should get around this: the above snippet should work even if Foo is imported from another crate.

The potential issue here is that adding implementations to any trait exported by a library is technically a breaking change (though I believe it is already in some circumstances due to method resolution, and also is with any other aspect of negative trait bounds).

[nikomatsakis]

I would prefer to leave that for future work, @dhardy -- I'd rather not open the door on negative where clauses just now, but also I think that it'd be interesting to discuss the best way to model mutually exclusive traits (e.g., maybe we want something that looks more like enums).

[fmease]

Should manually implementing !Copy be allowed (#70849 #101836)? I assume it should.

[Alxandr]

@fmease when is Copy ever implemented automatically?

[fmease]

@Alxandr Never, I know. This is just a corner case lacking practical relevance I think. I am just asking here to be able to decide whether the issue I linked is a diagnostics problem only or if the compiler is actually too strict / lax. There should be no harm in implementing !Copy as a signal to library users.

Edit: There might even be some benefit in doing that with negative coherence enabled.

[Bajix]

I think we should just rule out !Drop -- drop is a very special trait.

I found a use case for this while working on async-local; for types that don't impl Drop, the thread_local macro won't register destructor functions, and the lifetime of these types can be extended by using Condvar making it possible to hold references to thread locals owned by runtime worker threads in an async context or on any runtime managed thread so long as worker threads rendezvous while destroying thread local data. For types that do impl Drop, they will immediately deallocate regardless of whether the owning thread blocks and so synchronized shutdowns cannot mitigate the possibility of pointers being invalidated, making the safety of this dependent on types not implementing Drop.

[cynecx]

Conditional negative impls seem to be broken?

#![feature(auto_traits, negative_impls)]

unsafe auto trait Unmanaged {}

unsafe trait Trace {}

struct GcPtr(*const ());

unsafe impl Trace for GcPtr {}

// It seems like rustc ignores the `T: Trace` bound.
impl<T: Trace> !Unmanaged for T {}

fn check<T: Unmanaged>(_: T) {}

fn main() {
    let a = (0, 0);
    // error: the trait bound `({integer}, {integer}): Unmanaged` is not satisfied
    check(a);
}

[mejrs]

Conditional negative impls seem to be broken?

As far as I can tell this has never had defined semantics. See https://github.com/rust-lang/rust/issues/79098 also.

[Amanieu]

This came up in the libs-api meeting today while we were discussing https://github.com/rust-lang/libs-team/issues/175 which proposes adding PhantomUnSend and PhantomUnSync types to the standard library. We feel that it would be better to solve the ergonomics issue (using PhantomData to opt out of Send/Sync is... ugly) with a proper language feature.

How does the lang team feel about a partial stabilization of negative impls which only covers the specific use case of opting-out of OIBITs like Send/Sync/Unpin`?

[JohnScience]

For those who's wondering what OIBITs are,

The acronym “OIBIT”, while quite fun to say, is quite the anachronism. It stand for “opt-in builtin trait”.

Source: https://internals.rust-lang.org/t/pre-rfc-renaming-oibits-and-changing-their-declaration-syntax/3086

Also see https://github.com/rust-lang/rfcs/blob/master/text/0019-opt-in-builtin-traits.md.

[joshtriplett]

We discussed this in today's @rust-lang/lang meeting. We had a consensus in favor of stabilizing enough of negative impls here.

The subset we'd be in favor of stabilizing would be to require that the negative impl be "always applicable". Effectively, the impls can't have any bounds other than those required for an instance of the type. So, if struct Foo<T> requires T: Debug then you can impl<T> !Send for Foo<T> where T: Debug, but if struct Foo<T> doesn't require T: Debug then you can only impl<T> !Send for Foo<T> with no bounds on T.

One further consideration: a negative impl impl !Send for Foo isn't just "this is not Send", it's a promise that it won't become Send in the future. If a user wants "this is not Send but I'm making no promises that it won't be in the future", we would need something like impl ?Send for Foo. The lang team was generally in favor of adding this form as well.

[WaffleLapkin]

To add to the @joshtriplett's comment:

1. The "always applicable" rule is the same as we currently have for Drop
2. The rule that is easy to remember with negative impls is: it's always a breaking change to remove an implementation, both positive and negative ones
   • _{This rule would be somewhat more complex with "questionable implementations" if we end up adding them, since then it would be okay to remove those}

---

I've also volunteered to work on stabilization of this feature and related work here.

[ChayimFriedman2]

Are you proposing to also stabilize negative bounds (as a semver promise) for non-auto-traits? If not, how can removing a negative impl of an auto trait be a breaking change with any auto trait we have?

[scottmcm]

More on "questionable" impls:

• We've wanted these in the past for other reasons, and indeed have #[rustc_reservation_impl] (https://github.com/rust-lang/rust/pull/62661/files#diff-3f4f29f2f5d7a54d28195beb05a24a0736a64ffe35eb30d8e7b2227c6a2fd615R564) to make this possible in certain cases.

• I would love to have them in rustdocs for various things. If we can't yet agree on f32: !Ord, having a reserved impl Ord for f32; as a place to put "Look, it's intentional that this doesn't exist and here's what you should do instead".

• Similarly, that could replace a bunch of the on_implemented use cases. reserved impl FromResidual<Option<_>> for Result<_, _>; would be nicer than doing that with text, for example, and could hopefully let it use the real trait solver instead of a side system with its own quirks.

• They would also be great for new standard library traits, since they could start by always reserving impls for all our fundamental types. That would avoid problems like how we couldn't impl Extend for &mut impl Extend because of reference being fundamental, even though that would be useful to have.

• With the tweaked coherence rules, IIRC you might sometimes want in a library to reserve some things (particularly blanket impls) to be able to have the option of adding them later, since otherwise downstream crates might add conflicting impls on their own types.

[WaffleLapkin]

@ChayimFriedman2 no, negative bounds are a separate feature and there is no suggestions to stabilize that.

The reason removing a negative impl is a breaking change is that typechecker is allowed to assume that it is. It currently doesn't use this AFAIK, but in the feature we want to allow code like this:

struct NeverSend;
impl !Send for NeverSend {}

trait X {}

impl<T: Send> X for T {}
impl X for NeverSend {} // typechecked is allowed to assume those impl don't overlap

[spastorino]

@WaffleLapkin we were working on this with @lcnr and @nikomatsakis and at some point but the work was deferred. I'm happy if you can move this forward and I'd be interested in following along. I think I even have a couple of PRs about this half-baked that I'm not sure if are relevant anymore :). Feel free to reach out if I can help with things.

There's also the RFC draft that we were working in meetings with Niko https://hackmd.io/ZmpF0ITPRWKx6jYxgCWS7g

[joshtriplett]

@spastorino How easily could we add impl ?Send for SomeType?

[lcnr]

from a t-types pov it's pretty straightforward to implement with the following design constraints

• only allowed for auto traits
• required to be fully applicable, same as Drop

if t-lang decides that we should have that feature, it could be stabilized in 1-2 releases (assuming someone has the capacity to work)

[spastorino]

@lcnr :+1:, my understanding was also that this is "easy" to do. I'd be up for working on this impl ?Send for SomeType if t-lang decides to have the feature.

[Jules-Bertholet]

• Should we permit combining default + negative impls like default impl !Trait for Type { }? (Context)

One possibility would be to allow such impls to be specialized by a more specific positive impl defined in the same crate. This would provide a way of expressing that a positive impl is guaranteed not to be extended or generalized in the future.

[traviscross]

@rustbot labels -I-lang-nominated

We discussed this, as mentioned above, and the team was in favor of doing it. The next step would be someone putting together a concrete proposal, probably in the form of a stabilization PR with a suitably detailed stabilization report.

Until then, there's probably not much more to discuss, so we'll remove the nomination. As soon as the stabilization report / PR is posted, please nominate for T-lang.