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.

[jhpratt]

I believe this should be closed in favor of #39935, as the issue is largely the same.

[JohnScience]

Hi, I'm trying to provide feature-gated implementations of Extend<Group>, Extend<Literal>, etc, for proc_macro::TokenStream.

For that I've created a ts_extend_w_tt_item feature and right now I'm trying to do add the lines below to rust/library/proc_macro/src/lib.rs:

#[unstable(feature = "ts_extend_w_tt_item", issue = "112815")]
impl Extend<Group> for TokenStream {
    fn extend<I: IntoIterator<Item = Group>>(&mut self, groups: I) {
        self.extend(groups.into_iter().map(TokenTree::Group))
    }
}

#[unstable(feature = "ts_extend_w_tt_item", issue = "112815")]
impl Extend<Literal> for TokenStream {
    fn extend<I: IntoIterator<Item = Literal>>(&mut self, literals: I) {
        self.extend(literals.into_iter().map(TokenTree::Literal))
    }
}

#[unstable(feature = "ts_extend_w_tt_item", issue = "112815")]
impl Extend<Ident> for TokenStream {
    fn extend<I: IntoIterator<Item = Ident>>(&mut self, idents: I) {
        self.extend(idents.into_iter().map(TokenTree::Ident))
    }
}

#[unstable(feature = "ts_extend_w_tt_item", issue = "112815")]
impl Extend<Punct> for TokenStream {
    fn extend<I: IntoIterator<Item = Punct>>(&mut self, puncts: I) {
        self.extend(puncts.into_iter().map(TokenTree::Punct))
    }
}

However, I'm getting such errors:

error: an `#[unstable]` annotation here has no effect
   --> library\proc_macro\src\lib.rs:375:1
    |
375 | #[unstable(feature = "ts_extend_w_tt_item", issue = "112815")]
    | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
    |
    = note: see issue #55436 <https://github.com/rust-lang/rust/issues/55436> for more information

error: could not compile `proc_macro` (lib) due to 4 previous errors

I checked this issue and https://rustc-dev-guide.rust-lang.org/stability.html but I still don't understand what to do. Should I remove the feature-gate and provide the implementations unconditionally?

Update

I received a reply in the #contribute channel of the official Discord server of Rust programming language. There, jyn (jynelson) confirmed that I need to remove the feature-gate and make the implementation insta-stable.

If I understood him correctly, it means that I should proceed with the stabilization process immediately as described in Standard library developers Guide > 4. The feature lifecycle > 4.3 Stabilizing features.