Description
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?
-
compiles on stable, even though there is no obvious type for
fn foo(x: bool) -> impl Debug { if x { return vec!["hi"] } Default::default() }
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 aVec<&'static str>
impl Foo
can be used for associated types that expect a type that implementsBar
, even ifFoo
andBar
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
Metadata
Metadata
Assignees
Labels
Type
Projects
Status
Status