-
Notifications
You must be signed in to change notification settings - Fork 12.9k
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
Tracking issue for RFC 1951: Finalize syntax and parameter scoping for impl Trait
, while expanding it to arguments
#42183
Comments
I would hate to slow up
Currently I could do this with a trait object, but that would expose the dynamicness in my API. So instead I would create a new enum to hold the iterator. It looks like with |
@droundy That came up a few times, as creating an "intersection type", in your case it would be something like I am actually in favor of doing it, for |
If I'm understanding you, @eddyb, this means that this is case won't work in the current proposal, but there is room for a backwards compatible change that will enable automatic generation of sum types in the future? |
Yes, it only showed up in related discussion but is not part of any accepted proposal. |
Before landing anything here we should make sure we correctly handle (or error on) lifetime elision in The more conservative option is to just ban elision entirely for the time being. |
The case @droundy describes has a pretty common equivalent in futures, basically anywhere the |
I've certainly encountered the desire for |
@nikomatsakis I think there is a big difference between type-visible intersection types and those that would/could be hidden behind |
If you allow user matching on such types which is needed for manual impls, then |
I wrote a little bit about this a while ago, including what implementations could be synthesized automatically, and how trait authors could specify their own : |
My point is merely that we cannot always synthesize impls. I might be fine with saying "when the traits meets the required criteria, we will permit |
A thought from With this + dyn, we have fn foo(x: &dyn Trait)
fn foo(x: impl Trait)
impl Trait1 for dyn Trait2 { ... }
impl<T:Trait2> Trait1 for T { ... } Should the last of those also be "argument position" and thus this? (Eventually, at least.) impl Trait1 for impl Trait2 { ... } That's sortof logical, and |
impl Trait Lifetime Handling This PR implements the updated strategy for handling `impl Trait` lifetimes, as described in [RFC 1951](https://github.com/rust-lang/rfcs/blob/master/text/1951-expand-impl-trait.md) (cc #42183). With this PR, the `impl Trait` desugaring works as follows: ```rust fn foo<T, 'a, 'b, 'c>(...) -> impl Foo<'a, 'b> { ... } // desugars to exists type MyFoo<ParentT, 'parent_a, 'parent_b, 'parent_c, 'a, 'b>: Foo<'a, 'b>; fn foo<T, 'a, 'b, 'c>(...) -> MyFoo<T, 'static, 'static, 'static, 'a, 'b> { ... } ``` All of the in-scope (parent) generics are listed as parent generics of the anonymous type, with parent regions being replaced by `'static`. Parent regions referenced in the `impl Trait` return type are duplicated into the anonymous type's generics and mapped appropriately. One case came up that wasn't specified in the RFC: it's possible to write a return type that contains multiple regions, neither of which outlives the other. In that case, it's not clear what the required lifetime of the output type should be, so we generate an error. There's one remaining FIXME in one of the tests: `-> impl Foo<'a, 'b> + 'c` should be able to outlive both `'a` and `'b`, but not `'c`. Currently, it can't outlive any of them. @nikomatsakis and I have discussed this, and there are some complex interactions here if we ever allow `impl<'a, 'b> SomeTrait for AnonType<'a, 'b> { ... }`, so the plan is to hold off on this until we've got a better idea of what the interactions are here. cc #34511. Fixes #44727.
Can this be closed? #34511 is the tracking issue for further development of impl trait/abstract type. |
Closing in favor of #34511. |
This is a tracking issue for the RFC "Finalize syntax and parameter scoping for
impl Trait
, while expanding it to arguments" (rust-lang/rfcs#1951).Steps:
Unresolved questions:
impl Trait + 'a
need to be nailed down.Known bugs:
(this list is not necessarily exhaustive)
The text was updated successfully, but these errors were encountered: