This is a tracking issue for specialization (rust-lang/rfcs#1210).

Major implementation steps:

• Land Implement RFC 1210: impl specialization #30652 =)
• Restrictions around lifetime dispatch (currently a soundness hole)
• default impl (support default impl for specialization #37653)
• Integration with associated consts
• Bounds not always properly enforced (Trait bounds not checked on specializable associated types #33017)
• Should we permit empty impls if parent has no default members? 🛠️ specialization permits empty impls when parent has no default items #48444
• implement "always applicable" impls 🔬 implement "always applicable impls" #48538
• describe and test the precise cycle conditions around creating the specialization graph (see e.g. this comment, which noted that we have some very careful logic here today)

Unresolved questions from the RFC:

• Should associated type be specializable at all?
• When should projection reveal a default type? Never during typeck? Or when monomorphic?
• Should default trait items be considered default (i.e. specializable)?
• Should we have default impl (where all items are default) or partial impl (where default is opt-in); see support default impl for specialization #37653 (comment) for some relevant examples of where default impl is limiting.
• How should we deal with lifetime dispatchability?

Note that the specialization feature as implemented currently is unsound, which means that it can cause Undefined Behavior without unsafe code. min_specialization avoids most of the pitfalls.

Tracking issues have a tendency to become unmanageable. Please open a dedicated new issue and label it with F-specialization for absolutely any topics you want to discuss or have questions about. See rust-lang/compiler-team#739 for details and discussions on this prospective policy.