Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Meta tracking issue for impl Trait #63066

Open
1 of 11 tasks
Centril opened this issue Jul 28, 2019 · 14 comments
Open
1 of 11 tasks

Meta tracking issue for impl Trait #63066

Centril opened this issue Jul 28, 2019 · 14 comments

Comments

@Centril
Copy link
Contributor

@Centril Centril commented Jul 28, 2019

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;. #63063

    • Permit type Foo = impl Bar; in trait definitions. #29661
  • In const and static items and let bindings. #63065

  • Member constraints in region inference: #61997

  • Existential lifetimes. #60670

  • Support lifetime elision in argument position. #49287

  • 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.

  • 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
Copy link
Contributor

@kevincox kevincox commented Oct 16, 2019

#65481 Allow impl Trait in trait method return values.

Loading

@sighoya

This comment was marked as off-topic.

@Aaron1011

This comment was marked as off-topic.

@CryZe

This comment was marked as off-topic.

@sighoya

This comment was marked as off-topic.

@mark-i-m

This comment was marked as off-topic.

@CryZe

This comment was marked as off-topic.

@Centril
Copy link
Contributor Author

@Centril Centril commented Nov 17, 2019

@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.

Loading

strohel added a commit to strohel/rust that referenced this issue Mar 2, 2020
The existing issue rust-lang#34511
has been closed and replaced by meta-issue
rust-lang#63066

The concrete part of the new meta-issue for this
feature should be
rust-lang#63065
strohel added a commit to strohel/rust that referenced this issue Mar 2, 2020
The existing issue rust-lang#34511 has been closed and replaced by meta-issue rust-lang#63066.

The concrete part of the new meta-issue for this feature should be rust-lang#63065.
@rphmeier
Copy link
Contributor

@rphmeier rphmeier commented Jun 24, 2020

@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?

Loading

@Nemo157
Copy link
Member

@Nemo157 Nemo157 commented Jun 25, 2020

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)].

Loading

@rphmeier
Copy link
Contributor

@rphmeier rphmeier commented Jun 25, 2020

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.

Loading

@devxpy
Copy link

@devxpy devxpy commented Sep 6, 2020

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 })
	}
}

Loading

@ibraheemdev
Copy link
Contributor

@ibraheemdev ibraheemdev commented Jan 3, 2021

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...

Loading

@memoryruins
Copy link
Contributor

@memoryruins memoryruins commented Jan 3, 2021

Is there a tracking issue for named existential types?

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

Loading

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

None yet