Tracking issue for RFC 2532, "Associated type defaults" #29661

This is a tracking issue for the RFC "Associated type defaults" (rust-lang/rfcs#2532) under the feature gate #![feature(associated_type_defaults)].

The associated item RFC included the ability to provide defaults for associated types, with some tricky rules about how that would influence defaulted methods.

The early implementation of this feature was gated, because there is a widespread feeling that we want a different semantics from the RFC -- namely, that default methods should not be able to assume anything about associated types. This is especially true given the specialization RFC, which provides a much cleaner way of tailoring default implementations.

The new RFC, rust-lang/rfcs#2532, specifies that this should be the new semantics but has not been implemented yet. The existing behavior under #![feature(associated_type_defaults)] is buggy and does not conform to the new RFC. Consult it for a discussion on changes that will be made.

Steps:

• Implement RFC: Associated type defaults rfcs#2532 (cc @rust-lang/wg-traits @rust-lang/compiler)
  • Implement RFC 2532 – Associated Type Defaults #61812
  • handle associated_type_defaults are unsound in the new solver trait-system-refactor-initiative#46
  • Implement the changes to object types specified in the RFC
• Improve type mismatch errors when an associated type default can not be projected (Implement RFC 2532 – Associated Type Defaults #61812 (comment))
• Adjust documentation (see instructions on forge)
• Stabilization PR (see instructions on forge)

Unresolved questions:

• 1. When do suitability of defaults need to be proven?
• 2. Where are cycles checked?
• How do associated types interact with supertrait shadowing? (Since stabilizing associated type defaults would make adding associated types a non-breaking change.)

Test checklist

Originally created as a comment on #61812

• Trait objects and defaults
  • Independent defaults (type Foo = u8;)
    • where not specified (dyn Trait)
      • show that it's an error to coerce from dyn Trait<Foo = u16> to that
      • show that we assume it is u8 by invoking some method etc
    • where specified (dyn Trait<Foo = u16>)
      • show that it's an error to coerce from dyn Trait<Foo = u16> to that
      • show that we assume it is u8 by invoking some method etc
  • Mixed with type without a default (type Foo = u8; type Bar;)
    • where neither is specified (dyn Trait) -- error
    • where Foo is specified (dyn Trait<Foo = u16>) -- error
    • where Bar is specified (dyn Trait<Bar = u32>) -- ok, check Foo defaults to u8
    • where both are specified (dyn Trait<Foo = u16, Bar = u32>) -- ok
  • Dependent defaults (type Foo = u8; type Bar = Vec<Self::Foo>)
    • where neither is specified (dyn Trait) -- error
    • where Foo is specified (dyn Trait<Foo = u16>) -- unclear, maybe an error?
    • where Bar is specified (dyn Trait<Bar = u32>) -- unclear, maybe an error?
    • where both are specified (dyn Trait<Foo = u16, Bar = u32>) -- ok
  • Cyclic defaults (type Foo = Self::Bar; type Bar = Self::Foo)
    • where neither is specified (dyn Trait)
    • where Foo is specified (dyn Trait<Foo = u16>)
    • where Bar is specified (dyn Trait<Bar = u32>)
    • where both are specified (dyn Trait<Foo = u16, Bar = u32>)
  • Non-trivial recursive defaults (type Foo = Vec<Self::Bar>; type Bar = Box<Self::Foo>;)
    • where neither is specified (dyn Trait)
    • where Foo is specified (dyn Trait<Foo = u16>)
    • where Bar is specified (dyn Trait<Bar = u32>)
    • where both are specified (dyn Trait<Foo = u16, Bar = u32>)
• Specialization
  • Default values unknown in traits
  • trait definition cannot rely on type Foo = u8; (defaults-in-other-trait-items.rs)
  • impl for trait that manually specifies can rely
    • also, can rely on it from outside the impl
  • impl for trait that does not specify can rely
  • impl with default type Foo = u8, cannot rely on that internally (defaults-specialization.rs)
  • default impl with type Foo = u8, cannot rely on that internally (defaults-specialization.rs)
  • impl that specializes but manually specifies can rely
  • impl that specializes but does not specify can rely
    • right? want also a test that this impl cannot be further specialized -- is "default" inherited, in other words?
• Correct defaults in impls (type)
  • Independent defaults (type Foo = u8;)
    • overriding one default does not require overriding the others (associated-types/associated-types-overridden-default.rs)
      • (does not test that the projections are as expected)
    • where not specified (impl Trait { }) (associated-types/issue-54182-2.rs)
    • where specified (impl Trait { type Foo = u16; }) (issue-54182-1.rs)
  • Mixed with type without a default (type Foo = u8; type Bar;)
    • where neither is specified (impl Trait { }) -- error
    • where Foo is specified (impl Trait { type Foo = u16; }) -- error
    • where Bar is specified (impl Trait { type Bar = u32; }) -- ok
    • where both are specified (impl Trait { type Foo = u16; type Bar = u32; }) -- ok
  • Dependent defaults (type Foo = u8; type Bar = Vec<Self::Foo>) -- defaults-in-other-trait-items-pass.rs, defaults-in-other-trait-items-fail.rs
    • where neither is specified (impl Trait { })
    • where Foo is specified (impl Trait { type Foo = u16; })
    • where Bar is specified (impl Trait { type Bar = u32; })
    • where both are specified (impl Trait { type Foo = u16; type Bar = u32; })
  • Cyclic defaults (type Foo = Self::Bar; type Bar = Self::Foo) -- defaults-cyclic-fail.rs, defaults-cyclic-pass.rs
    • where neither is specified (impl Trait { })
      • considered to be an error only if a projection takes place (is this what we want?)
    • where Foo is specified (impl Trait { type Foo = u16; })
    • where Bar is specified (impl Trait { type Bar = u32; })
    • where both are specified (impl Trait { type Foo = u16; type Bar = u32; })
  • Non-trivial recursive defaults (type Foo = Vec<Self::Bar>; type Bar = Box<Self::Foo>;)
    • where neither is specified (impl Trait { })
    • where Foo is specified (impl Trait { type Foo = u16; })
    • where Bar is specified (impl Trait { type Bar = u32; })
    • where both are specified (impl Trait { type Foo = u16; type Bar = u32; })
• Correct defaults in impls (const)
  • Independent defaults
    • where not specified
    • where specified
  • Mixed with type without a default
    • where neither is specified
    • where Foo is specified
    • where Bar is specified
    • where both are specified
  • Dependent defaults
    • where neither is specified
    • where Foo is specified
    • where Bar is specified
    • where both are specified
  • Cyclic defaults -- defaults-cyclic-fail.rs, defaults-cyclic-pass.rs
    • where neither is specified (impl Trait { })
      • considered to be an error only if a projection takes place (is this what we want?)
    • where Foo is specified
    • where Bar is specified
    • where both are specified
  • Non-trivial recursive defaults
    • where neither is specified
    • where Foo is specified
    • where Bar is specified
    • where both are specified
• Overflow errors in const evaluation
  • check that errors in evaluation do not occur based on default values, but only the final values
  • Dependent defaults (defaults-not-assumed-fail, defaults-not-assumed-pass)
    • where neither is specified
    • where Foo is specified
    • where Bar is specified
    • where both are specified
• WF checking (defaults-suitability.rs)
  • requires that defaults meet WF check requirements (is this what we want?)
  • type in trait body, bound appears on the item
  • type in trait body, type not wf
  • type in trait body, bound appears as trait where clause
  • default type in impl, bound appears on the item
  • type in impl, bound appears on the item
  • type in default impl, bound appears on the item
  • type in trait body, conditionally wf depending on another default
    • currently gives an error (is this what we want?)
  • type in trait body, depends on another default whose bounds suffice