Meta tracking issue for `impl Trait`

[Centril]

This issue tracks the progress of impl Trait in general.

This issue is not for discussion about specific extensions to impl Trait and only exists to provide links to other places that track the progress of specific issues. If you wish to discuss some subject related to impl Trait, please find an existing appropriate issue below or create an new issue and comment here with a link to the newly created issue.

---

The impl Trait related issues currently on deck are as follows:

• Label A-impl-trait
• Permit type Foo = impl Bar;. Tracking issue for RFC 2515, "Permit impl Trait in type aliases" #63063
  • Permit type Foo = impl Bar; in trait definitions. Tracking issue for RFC 2532, "Associated type defaults" #29661
• In const and static items and let bindings. Tracking issue for impl Trait in const and static items and let bindings #63065
• Member constraints in region inference: Tracking issue for member constraints in region inference #61997
• Existential lifetimes. Tracking issue for existential lifetimes #60670
• Support lifetime elision in argument position. Argument-position impl Trait requires a named lifetime #49287
• Should we allow impl Trait after -> in fn types or parentheses sugar? [impl Trait] Should we allow impl Trait after -> in fn types or parentheses sugar? #45994
• Do we have to impose a DAG across all functions to allow for auto-safe leakage, or can we use some kind of deferral.
  • Discussion: Implement impl Trait in return type position by anonymization. #35091 (comment)
  • Present semantics: DAG.
• Should we permit specifying types if some parameters are implicit and some are explicit? e.g., fn foo<T>(x: impl Iterator<Item = T>>)?
  • Current behavior: An error to specify types
  • Other alternatives: [treat impl Trait as arguments in the list, permitting migration]
• Some concerns about nested impl Trait usage

---

Open RFCs:

None.

[kevincox]

#65481 Allow impl Trait in trait method return values.

[sighoya]

What about impl Trait implementing Traits?

trait Trait {...}
impl Trait for impl AnotherTrait {...}

[Aaron1011]

@sighoya: Each occurence of impl MyTrait produces a unique type (e.g. fn foo() -> impl MyTrait and fn bar() -> impl MyTrait do not return the same type).

This means that impl Trait for impl AnotherTrait {...} would be almost completely useless - it would create a new type, implement a type for it, but give you no way of referring to that type.

You might be thinking of type-alias-impl-trait (e.g. type Foo = impl MyTrait). However, using these types in impl blocks is explicitly ruled out by the RFC

[CryZe]

Well in that position, impl Trait would be a generic T with the trait as the bound <T: Trait>, so

impl Trait for impl AnotherTrait { ... }

desugars to

impl<T: AnotherTrait> Trait for T { ... }

[sighoya]

Thank you both,

I think the difference between a impl Trait and a dyn Trait is that the first one is a design time existential even in argument position which get monomorphized at compile time, the latter is a compile time existential which gets monomorphized at runtime.

They should both behave mostly the same in my eyes. Implementing by an impl Trait or dyn Trait should state that every T bounded by this trait implements the trait being implemented.
If this is done twice:

impl Trait for impl AnotherTrait { ... }
impl<T: AnotherTrait> Trait for T { ... }
//or
impl Trait for dyn AnotherTrait { ... }
impl<T: AnotherTrait> Trait for T { ... }

then, the decision is made in favor for the implementation dependent on the given context.

[mark-i-m]

impl Trait for dyn AnotherTrait { ... }

What would this even mean? How do you implement something for type the compiler can't know?