-
Notifications
You must be signed in to change notification settings - Fork 13.6k
Open
Labels
A-stabilityArea: `#[stable]`, `#[unstable]` etc.Area: `#[stable]`, `#[unstable]` etc.A-trait-systemArea: Trait systemArea: Trait systemT-compilerRelevant to the compiler team, which will review and decide on the PR/issue.Relevant to the compiler team, which will review and decide on the PR/issue.T-typesRelevant to the types team, which will review and decide on the PR/issue.Relevant to the types team, which will review and decide on the PR/issue.
Description
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?
This issue has been assigned to @tiif via this comment.
Metadata
Metadata
Assignees
Labels
A-stabilityArea: `#[stable]`, `#[unstable]` etc.Area: `#[stable]`, `#[unstable]` etc.A-trait-systemArea: Trait systemArea: Trait systemT-compilerRelevant to the compiler team, which will review and decide on the PR/issue.Relevant to the compiler team, which will review and decide on the PR/issue.T-typesRelevant to the types team, which will review and decide on the PR/issue.Relevant to the types team, which will review and decide on the PR/issue.