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

[Centril]

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

[alexreg]

@varkor See my comment about the PR for this in the other thread, and let me know if you'd like me to take up your existing PR and finish it off maybe. :-)

[varkor]

@alexreg: thanks for the offer — I'll try to get a PR open this week, but if I turn out not to have enough time, I may pass it on to you :)

[Nemo157]

It appears that the current implementation does not trigger any "private type in public interface" errors, for the following code (playground):

#![feature(existential_type)]

#[derive(Debug)]
struct Bar(usize);

existential type Foo: std::fmt::Debug;

pub fn foo() -> Foo {
    Bar(5)
}

I would expect it to give an error like

error[E0446]: private type alias `Foo` in public interface
  --> src/lib.rs:8:1
   |
5  |   existential type Foo: std::fmt::Debug
   |   - `Foo` declared as private
...
8  | / pub fn foo() -> Foo {
9  | |     Bar(5)
10 | | }
   | |_^ can't leak private type alias

(although, because normal type aliases are transparent to the visibility checking, I'm not certain exactly what the error message should say; it just seems bad to introduce another way to accidentally forget to make part of your API publicly nameable)

EDIT: Opened #63169