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?
• 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

[SimonSapin]

One use case I’ve had for this is a default method whose return type is an associated type:

/// "Callbacks" for a push-based parser
trait Sink {
    fn handle_foo(&mut self, ...);
    // ...

    type Output = Self;
    fn finish(self) -> Self::Output { self }
}

This means that Output and finish need to agree with each other any given impl. (So they often need to be overridden together.)

default methods should not be able to assume anything about associated types.

This seems very restrictive (and in particular would prevent my use case). What’s the reason for this?

[aturon]

@SimonSapin

This seems very restrictive (and in particular would prevent my use case). What’s the reason for this?

There is a basic tradeoff here, having to do with soundness. Basically, there are two options at the extreme:

• Do not allow default methods to assume anything about defaulted associated types; in return, you can pick and choose which defaults to use in your impl.
• Allow default methods to "see" defaulted associated types; in return, if you override any defaulted associated types, you have to override all defaulted methods. Otherwise, you could get unsound code (based on incorrect type assumptions).

This is described in slightly more detail in the RFC.

Originally we proposed to go with the second route, but it has tended to feel pretty hokey, and we've been leaning more toward the first route.

(Incidentally, much the same question comes up for specialization.)

I'm happy to elaborate further, but wanted to jot off a quick response for now.

[SimonSapin]

Would it be possible to track which default methods rely of which associated types being the default, so that only those need to be overridden?

[aturon]

@SimonSapin Possibly, but we have a pretty strong bias toward being explicit in signatures about that sort of thing, rather than trying to infer it from the code. It's always a bad surprise when changing the body of a function in one place can cause a downstream crate to fail typechecking.

You could consider having some explicit "grouping" of items that get to see a given default associated type.

I'm not sure if you've been following the specialization RFC, but part of the proposal is a generalization of default implementations in traits. Imagine something like the following alternative design for Add (rather than having AddAssign separately):

trait Add<Rhs=Self> {
    type Output;
    fn add(self, rhs: Rhs) -> Self::Output;
    fn add_assign(&mut self, Rhs);
}

// the `default` qualifier here means (1) not all items are impled
// and (2) those that are can be further specialized
default impl<T: Clone, Rhs> Add<Rhs> for T {
    fn add_assign(&mut self, rhs: R) {
        let tmp = self.clone() + rhs;
        *self = tmp;
    }
}

This feature lets you refine default implementations given additional type information. You can have many such default impl blocks for a given trait, and the follow specialization rules.

The fact that you can have multiple such blocks might give us a natural way to delimit the scopes in which associated types are visible (and hence in which the methods have to be overridden when those types are).

[aturon]

(cc @nikomatsakis on that last comment)

[nikomatsakis]

@aturon I assume you mean specifically this last paragraph:

The fact that you can have multiple such blocks might give us a natural way to delimit the scopes in which associated types are visible (and hence in which the methods have to be overridden when those types are).

I find this idea appealing, I just think we have to square it away carefully, especially with the precise fn types we ought to be using. :)

[sunjay]

Is this feature still being worked on?

What do you think of something like this as a use case for this feature?

trait Bar {
    type Foo;
    // We want to default to just using Foo as its DetailedVariant
    type DetailedFoo = Self::Foo;

    // ...other trait methods...

    fn detailed(&self) -> DetailedFoo;

    // ...other trait methods...
}

[nikomatsakis]

@sunjay nobody is working on this, I think we are still unsure what semantics we would want to have.