Interactions in `type_alias_impl_trait` and `associated_type_defaults`

[Centril]

A question about impl Trait in trait type aliases: has any thought been given about how they should handle defaults?

I'm trying to do something like this, without success:

#![feature(type_alias_impl_trait, associated_type_defaults)]

use std::fmt::Debug;

struct Foo {
}

trait Bar {
    type T: Debug = impl Debug;
    fn bar() -> Self::T {
        ()
    }
}

impl Bar for Foo {
    type T = impl Debug;
    fn bar() -> Self::T {
        ()
    }
}

(playground link)

I'd guess this just hasn't been RFC'd yes, but does someone know if thought on the topic have already started?

Originally posted by @Ekleog in #63063 (comment)

[tema3210]

Maybe wrong issue, but I guess that this question might be better answered in prospect of specialization: what if we do:

• type T = impl Trait => abstract type T known to implement Trait, unspecializable, but a concrete type can be change in different impls.
• default type T = impl Trait => opaque type declaration, same as previous; can be specialized, but only by an opaque type declaration implementing at least Trait; e.g. default type T = impl Trait1 + Trait2 is more specific than default type T = impl Trait1.
• default type T = Type declaration where Type is a concrete type is forbidden. The reason for this is that there are no way how changing associated type in a more concrete impl. wouldn't break users of the trait.
  The problem is that such usage of specialization is canonical action at a distance: consider example: adding a more specific impl. changes return type of a method everywhere, even if the change couldn't be expected by the code (it's in another crate, etc.). The only save from this issue is to make T from the declaration opaque, but that's exactly what rule 2 is about.
• In case of somewhere down the specialization hierarchy some impl omits default modifier in type declaration, the type is considered final and cannot be specialized further.
• Validity of defining uses (does, for example, a struct implement a specific set of traits) of a TAIT item must be checked against the most specific opaque type declaration (default type T = impl Trait; "plain" type T = impl Trait declaration is the most specific opaque type declaration).

By this, your original example falls under the rule 1 and should be perfectly fine.

P.S. My wording may be bad....

Edit: fixed typos, add the last rule I was unsure about at first.

[Xiretza]

Should the type T = impl Debug; in the trait impl really be required? Shouldn't this also work?

#![feature(type_alias_impl_trait, associated_type_defaults)]

use std::fmt::Debug;

struct Foo;

trait Bar {
    type T: Debug = impl Debug;
    fn bar() -> Self::T {
        ()
    }
}

impl Bar for Foo {
    fn bar() -> Self::T {
        ()
    }
}

With a type T: Debug = impl Debug; in the trait declaration, it's clear that a concrete type still has to be decided by the trait impl; it can either use type T = Concrete; to override the opaqueness, or do nothing at all to "inherit" the opaque associated type from the default.