This is a tracking issue for the RFC “Permit impl Trait in type aliases” (rust-lang/rfcs#2515) which is implemented under the following #![feature(..)] gates:

• type_alias_impl_trait
• impl_trait_in_assoc_type: Split out a separate feature gate for impl trait in associated types #110237

About tracking issues

Tracking issues are used to record the overall progress of implementation. They are also uses as hubs connecting to other relevant issues, e.g., bugs or open design questions. A tracking issue is however not meant for large scale discussion, questions, or bug reports about a feature. Instead, open a dedicated issue for the specific matter and add the relevant feature gate label.

Steps

• Implement the RFC
• Adjust documentation (see instructions on rustc-guide)
• Stabilization PR (see instructions on rustc-guide)

Unresolved questions

Exactly what should count as “defining uses” for opaque types?

• Should the set of “defining uses” for an opaque type in an impl be just items of the impl, or include nested items within the impl functions etc? (see here for example)
• should return-position-impl-trait also start allowing nested functions and closures to affect the hidden type? – independent question to be answered separately by the lang team. Would simplify compiler.

can we come up with consistent rules when cross-usage type inference can happen?

fn foo(x: bool) -> impl Debug {
if x { return vec!["hi"] }
Default::default()
}

compiles on stable, even though there is no obvious type for Default::default() to produce a value of. We combine all return sites though and compute a shared type across them, so we’ll figure out a Vec<&'static str>

• impl Foo can be used for associated types that expect a type that implements Bar, even if Foo and Bar are entirely unrelated. The hidden type must satisfy both. See https://github.com/rust-lang/rust/pull/99860/files for examples.

impl traits in consts through const fns are allowed but shouldn’t be: impl traits in consts through const fns are allowed but shouldn’t #87277

when a type alias refers to other type aliases, opaque types from them are collected by #[define_opaque], too. See Add #[define_opaques] attribute and require it for all type-alias-impl-trait sites that register a hidden type #128440 for some examples (tests/ui/impl-trait/issue-108592.rs