Tracking Issue for auto traits (auto_traits) -- formerly called opt-in built-in traits (optin_builtin_traits) (original) (raw)

Skip to content

Navigation Menu

• • GitHub Copilot Write better code with AI
  • GitHub Models New Manage and compare prompts
  • GitHub Advanced Security Find and fix vulnerabilities
  • Actions Automate any workflow
  • Codespaces Instant dev environments
  • Issues Plan and track work
  • Code Review Manage code changes
  • Discussions Collaborate outside of code
  • Code Search Find more, search less
• Explore
  • Learning Pathways
  • Events & Webinars
  • Ebooks & Whitepapers
  • Customer Stories
  • Partners
  • Executive Insights
• • GitHub Sponsors Fund open source developers
  • The ReadME Project GitHub community articles
• • Enterprise platform AI-powered developer platform
• Pricing

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Sign up

Appearance settings

Description

This is the tracking issue for RFC 19.

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
• 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 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 (auto_traits) -- formerly called opt-in built-in traits (optin_builtin_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 (auto_traits) -- formerly called opt-in built-in traits (optin_builtin_traits) #13231 (comment)