Tracking issue for auto traits

[flaper87]

View all comments

This is a tracking issue for RFC 19 / RFC 127.
The feature gate for the issue is #![feature(auto_traits)].

Note

This feature used to be called opt-in built-in traits (gated behind optin_builtin_traits) and
used to include negative negative impls (now gated behind negative_impls; tracking issue: #68318).

About tracking issues

Tracking issues are used to record the overall progress of implementation.
They are also used as hubs connecting to other relevant issues, e.g., bugs or open design questions.
A tracking issue is however not meant for large scale discussion, questions, or bug reports about a feature.
Instead, open a dedicated issue for the specific matter and add the relevant feature gate label.

Implementation history

Completed Checklist (Historical)

Checklist

Here is a check-list of code to write and tricky scenarios to be sure we handle:

• forbid conditional negative impls as described here (negative impls are no longer part of this feature)
  • now tracked in forbid conditional, negative impls #79098 instead
• conditional negative impls not properly enforced Bounds seem to be ignored in negative impls #23072
• impl !Pod for .. should not be legal Negative blanket OIBIT impl treated as positive #28475
• fix feature-gate for impl Foo for .. impl Trait for .. {} does not require a feature gate #23225
• defaulted traits ought to be have more restrictive coherence rules defaulted traits ought to be have more restrictive coherence rules #22978
• defaulted traits should have no methods ICE: "resolved vtable bad vtable" with impl Trait for .. {} #23080 / Check that traits with default impls have no methods #23117
• Add parser support for impl Foo for ..
• Port Send/Sync to use new infrastructure internally
• Add unsafe impl Send for .. / unsafe impl Sync for ..
• Object types should never match against a defaulted trait (though the object type itself may add a candidate for traits that appear in the object type)
• When a defaulted trait matches, it should impose any supertrait bounds on the matched type as nested obligations
• Be wary of type inference -- if we haven't resolved a type yet, we have to be ambiguous
• Systematic testing for constituent_types
• Coherence interaction: a defaulted trait can only be implemented for structs/enums
• Coherence interaction: a trait can only be defaulted in the crate where it is defined
• Coherence interaction: a trait can only be defaulted once
• Coherence interaction: an auto-trait can be redundantly implemented for an object that has it - It is possible to redundantly implement an auto trait for a trait-object type #56934
• Defaulted impls cannot be generic
• Fix the interaction with PhantomData. OIBIT should treat PhantomData as if there were an instance of T reachable rather than breaking it down like it would a different struct. OIBIT: for PhantomData<T> check T rather than the struct itself #23091
• Allow negative implementations for traits that have a default implementation (besides Send/Sync).
• ICE "wrong number of generic parameters" with abused auto trait #104808 lifetimes on auto traits are buggy
• Coherence rules: is impl AutoTrait for dyn Trait legal? Tracking issue for auto traits #13231 (comment)
• Interaction with dyn safety. Autotrait bounds on dyn-safe trait methods #107082
• Do [u8] negative impls affect str. Tracking issue for auto traits #13231 (comment)

• Add syntax for negative implementations of traits #20285
• Add support for default trait implementations #21689
• Add defaulted impls for Send and Sync #23211
• […] TODO: recover these parts of the impl history
• Rename optin_builtin_traits to auto_traits #79336
• […] TODO: recover these parts of the impl history

[pnkfelix]

Marking 1.0, P-backcompat-lang.

[nikomatsakis]

cc me

[flaper87]

I'm actively working on this. Unfortunately, I've moved quite slowly because of other bugs I had to fix. I hope to be able to submit a PR this week.