Tracking issue for rustc_reservation_impl attribute

[nikomatsakis]

Background

The #[rustc_reservation_impl] attribute was added as part of the effort to stabilize !. Its goal is to make it possible to add a impl<T> From<!> for T impl in the future by disallowing downstream crates to do negative reasoning that might conflict with that.

Warning: the effect of this attribute is quite subtle, and it should be used with caution! In particular, adding a "reservation impl" alone does not guarantee that one can add the impl in the future, as described below.

History

• Initial implementation in reserve impl<T> From<!> for T #62661

Current blockers before this attribute can be used to affect end-users

• How should "reserved" impls show up in rustdoc? (How to handle reservation impls in rustdoc / error messages #64633)
• What should its error message be? (How to handle reservation impls in rustdoc / error messages #64633)

Usage

You can use the #[rustc_reservation_impl] attribute as follows:

#[rustc_reservation_impl]
impl<T> From<!> for T { .. }

For the most part, rustc will act as though this impl does not exist. For example, users can add overlapping impls if they prefer:

struct LocalType1<T>(T);
impl<T> From<!> for LocalType1<T> { }

struct LocalType2<T>(T);
impl<T> From<T> for LocalType2<T> { }

Note that this implies that the #[rustc_reservation_impl] attribute alone does not guarantee that you can add the reservation impl in a future compatible way. Adding the reserved impl in the future may still cause coherence overlap (e.g., the impl for LocalType<T> for the impl for all T would overlap here). This will typically result in errors.

In order to add the impl, you must be able to ensure that coherence will allow the overlapping impls. This can be done in two ways, both of which are presently unstable:

• Specialization: but be careful! e.g., the current specialization rules do not suffice in the LocalType2 example above, since neither impl is a subset of one another.
• Marker traits: we have a notion of marker traits that are allowed to overlap. Marker traits currently must have no items, which excludes e.g. From, but we could grow this definition.

What does the attribute do?

The attribute prevents negative reasoning. In particular, it forbids impls like this:

trait LocalTrait;
struct LocalType3;
impl<T> LocalTrait for T where T: From<!> { }
impl<T> LocalTrait for LocalType3 { }

Without the reservation impl, this would be legal, because the crate may assume that LocalType: From<!> does not hold (since LocalType is local to the crate). With the reservation impl, however, code like this will get an error.

[nikomatsakis]

We visited this during lang team backlog bonanza. Conclusions:

• This was never meant to be an end-user feature, it is a temporary crutch and at most perma-unstable.
• It's quite special purpose to ! -- there could be a useful end-user feature of "reserving" space to add an impl later, but this feature permits people to add things that overlap the intended impl, because we wanted people to be able to add impl From<!> for MyType even though we couldn't yet add the blanket impl (can't remember why).
• We didn't think it was a good idea to remove it immediately, because it might be useful if we move to stabilize ! again.

[Pr0methean]

I say we should fix whatever's preventing the blanket impl. Implementations of a method that the compiler can prove is unreachable shouldn't be able to conflict with each other -- otherwise it'd be like making Clone and Debug conflict just because they both don't implement kwyjibo(&self) -> (u32,u8,u8,u16,Result<Vec<u8>,Vec<()>>).