Impl stability is not checked

[qnighy]

Found this implementing #55431. There I want to make an unstable impl for a stable trait with stable types. We can mark impls #[unstable], but they seem to be just ignored.

#[unstable(feature = "boxed_closure_impls", ...)] // This seems to be ignored!
impl<A, F: FnOnce<A> + ?Sized> FnOnce<A> for Box<F> { ... }

A similar case is the CoerceUnsized impl for NonNull types. This is marked #[unstable] but can be used indirectly through coercion. These #[unstable] markers don't show up in rustdoc as well.

Questions:

• Is this a bug (or an unimplemented feature)? I currently suspect that it's the case, because stability will get complicated when trait solver is involved.
• If we implement this...
  • When should we consider them unstable? In my mind, coherence checking should always see all impls as visible. The hidden impls RFC (RFC: Hidden trait implementations rfcs#2529) may have a similar idea.
  • How should unstable traits behave with respect to type inference? I think they should be removed from candidates in winnowing if there are multiple options, and selected impls should be double-checked.
  • Do we need an RFC in this case?

[nagisa]

Implementations are intentionally insta-stable. It is a long-standing, and well known, limitation.

[qnighy]

Thank you!

Implementations are intentionally insta-stable. It is a long-standing, and well known, limitation.

I'd like to know the intention behind that, but I couldn't find related discussions by myself. I'll be happy if you have any references.

[petrochenkov]

I'd like to know the intention behind that

The "intention" is that it was hard to implement, so nobody implemented it, so stability attributes on impls now used only as documentation.

[qnighy]

The "intention" is that it was hard to implement, so nobody implemented it, so stability attributes on impls now used only as documentation.

Thanks! So there's no known problem with actually implementing it, but it's just (maybe) hard.

[petrochenkov]

There's just so many ways to use an impl - starting from direct impl method calls, to checking that a type passed as a generic argument satisfies a bound, to conversion of a concrete type with an unstable impl into a trait object.
All this felt radically different from pretty simple things that the stability pass did (you see a path/method call/field access, get its definition, check it for stability).
IIUC, the trait system was completely rewritten since then, so perhaps this checking can be done in some more centralized way now.

[cyplo]

Would it need an RFC or is it good for someone to just go and implement ?

[jonas-schievink]

@cyplo I don't think it needs an RFC, but the implementation is not going to be easy. It might be better to wait for chalk integration, which could simplify this.