Tracking issue for RFC 2532, "Associated type defaults"

[aturon]

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?

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

[sam0x17]

Just an FYI if anyone needs something now in stable rust that provides associated type defaults / default associated types, my supertrait crate can do it :)

[Sajjon]

Any ETA on when we might see this in Stable? Next year perhaps?

[Caellian]

Any ETA on when we might see this in Stable? Next year perhaps?

This is a tracking issue, a better place to ask this is on Zulip. ETA is impossible to give as there's still some unresolved questions about this feature and how it should be implemented that need to be resolved before someone starts working on it - check the linked issues and offer suggestions if you have any in the meantime.

[tgross35]

If anyone wants to pick part of this up, I think the biggest thing missing is support for dyn trait objects. That is, this should compile:

#![feature(associated_type_defaults)]
#![allow(unused)]

trait Trait {
    type Foo = u8;
    fn foo(&self) -> Self::Foo;
}

fn dyn_with_default_ty(a: &dyn Trait) -> u8 {
    a.foo()
}

Currently it fails with E0191 "the value of the associated type Foo in Trait must be specified"

This can probably reuse a lot of the same logic as for generics T: Trait (introduced in the original PR #61812), which should sidestep a lot of bugs. Many of the tests in test/ui/associated-types/default* can probably be duplicated to test defaults with dyn.

---

Other than that, @nikomatsakis (or others) what is meant by Correct defaults in impls (const) in the top post? Does that just mean adding tests for this:

trait Trait {
    type Foo = u8;
    // currently "associated type defaults can't be assumed inside the trait defining them"
    const Bar: Self::Foo = 100;
}

Which AIUI is rejected by the RFC, meaning the compiler handles it correctly.

[tgross35]

@Centril I don't know if you are still active, but maybe you have some insight as the author of that incredibly complete RFC :)

[Veetaha]

I've just checked this feature against the compilation benchmarks of my proc-macro crate, that generates a big amount of repetitive trait implementations with associated types. The results of current benchmarks on stable are documented here.

After I updated the macro impl to use associated type defaults this has removed the quadratic growth of the generated source code, and the compilation time improved:

• "10 structs with 50 fields" decreased from 2.096s to 0.878s (58% compilation perf. increase)
• "100 structs with 10 fields" decreased from 2.340s to 1.961s (16% compilation perf. increase)

I wonder if it would be possible to stabilize a conservative MVP subset of this feature that assumes:

• non-object-safe traits
• definition-site checks for defaults suitability
• definition-site checks for cycles

This would still bring these compilation time improvements to stable