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.

[Centril]

@sighoya @Aaron1011 @mark-i-m @CryZe This issue is not for general discussion about impl Trait. It's only intended to collect links.

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.

[rphmeier]

@Centril

Permit type Foo = impl Bar; in trait definitions

This links to #29661 which seems to be about setting associated type defaults, whereas I understood the text to mean something like this:

trait SomeTrait {
    type Foo: Bar;

    fn foo() -> Self::Foo;
}

impl SomeTrait for X {
    type Foo = impl Bar;

    fn foo() -> Self::Foo { ... }
}

I didn't perceive #29661 to be about this use-case, but instead about something different:

trait SomeTrait {
    type Foo: Bar = SomeSpecificBar;
}

I understood "type Foo = impl Bar in trait definitions" to mean my first example and to be one of the end goals of impl Trait. Is there an issue tracking that specific feature that can be linked to?

[Nemo157]

Trait definitions is your second example, covered by #29661. Your first example is trait implementations, which is covered by RFC 2515 (#63063), specifically the last example of RFC 2515 § Guide-level explanation § Type alias, and it currently works on nightly with #![feature(type_alias_impl_trait)].

[rphmeier]

Thanks @Nemo157. I would find amendment to the issue text here to make clear that the link to #63063 also encompasses trait implementations and that the sub-link to #29661 is only about associated type defaults helpful. At the moment, the implication of the text is that #63063 is only about "bare" type aliases and #29661 is about impl Trait in associated types.

[devxpy]

Hello, does this include allowing impl Trait in structs? (something RFC2071 may have solved)

E.g. -

struct Session {
    client: websocket::sync::Client<impl websocket::sync::Stream>
}

error[E0562]: `impl Trait` not allowed outside of function and inherent method return types
   --> src/main.rs:139:37
    |
139 |     client: websocket::sync::Client<impl websocket::sync::Stream>,
    |                                     ^^^^^^^^^^^^^^^^^^^^^^^^^^^^

---

The current workaround for doing this is quite unergonomic -

use anyhow::Result;
use websocket;

fn main() -> Result<()> {
    let session = create_session()?;
    Ok(())
}

struct Session<T: websocket::sync::Stream> {
    client: websocket::sync::Client<T>,
}

fn create_session() -> Result<Session<impl websocket::sync::Stream>> {
    let client = websocket::ClientBuilder::new("ws://...")?.connect_insecure()?;
    Ok(Session { client })
} 

Source

vs if this was implemented -

use anyhow::Result;
use websocket;

fn main() -> Result<()> {
    let session = Session::new()?;
    Ok(())
}

struct Session {
    client: websocket::sync::Client<impl websocket::sync::Stream>
}

impl Session {
	fn new() -> Result<Self> {
	    let client = websocket::ClientBuilder::new("ws://...")?.connect_insecure()?;
	    Ok(Session { client })
	}
}

[ibraheemdev]

Is there a tracking issue for named existential types? The original tracking issue (#44685) was closed as a duplicate of #34511, which was closed in favor of this issue, but I don't see named existential types mentioned anywhere here...

[memoryruins]

Is there a tracking issue for named existential types?

@ibraheemdev #63063
https://rust-lang.github.io/rfcs/2515-type_alias_impl_trait.html