Tracking issue for RFC 2515, "Permit impl Trait in type aliases"

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 used 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
Stabilize -Znext-solver Tracking Issue for -Znext-solver #107374
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

Rollup merge of rust-lang#63092 - Centril:update-impl-trait-gates, r=…

refactor: clean up imports and remove redundant comments

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.

please take this to a new issue, there are lots of people subscribed to tracking issues and this isn't the place for general discussion about the feature

@Houtamelo

@Houtamelo that is explained at the top of this thread

Tracking issues are used to record the overall progress of implementation.
They are also used 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.

Navigation Menu

Repository navigation

Tracking issue for RFC 2515, "Permit impl Trait in type aliases" #63063

About tracking issues

Steps

Unresolved questions

311 remaining items

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Tracking issue for RFC 2515, "Permit impl Trait in type aliases" #63063

Description

About tracking issues

Steps

Unresolved questions

Activity

alexreg commented on Jul 28, 2019

varkor commented on Jul 28, 2019

Nemo157 commented on Jul 31, 2019

crlf0710 commented on Aug 3, 2019

311 remaining items

Evian-Zhang commented on Feb 23, 2025

traviscross commented on Feb 23, 2025

Houtamelo commented on Jan 4, 2026

software-artificer commented on Jan 4, 2026

BoxyUwU commented on Jan 4, 2026

Houtamelo commented on Jan 4, 2026

RalfJung commented on Jan 5, 2026

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions