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

  • 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

[Centril]

In #63092, landed on 2019-07-28, written by @Centril and reviewed by @varkor, the tracking issue for existential_type was adjusted to this one.

In #63096, landed on 2019-07-29, written by @Centril and reviewed by @varkor, 3 ICEs were closed with reproducer tests added.

In #63158, landed on 2019-07-31, written by @JohnTitor and reviewed by @Centril, 1 ICE was closed with a reproducer test added.

In #63180, landed on 2019-08-03, written by @varkor and reviewed by @Centril, the syntax was changed to type Foo = impl Bar; through a temporary hack in the parser. @varkor will follow up to remove that hack. The new feature gate name is type_alias_impl_trait and the old one existential_type has been removed.

In rust-lang/rustc-dev-guide#402, landed on 2019-08-29, written by @varkor and reviewed by @mark-i-m, @Arnavion, and @spastorino, the rustc guide description was updated.

[ebkalderon]

@Veykril That's a neat trick! Is this something we wish to encourage users to do with TAIT long term, though? Or will we be relaxing the rules somewhat so that this empty where X: clause isn't necessary? I admit, this does seem like a bit of a hack. I understand that this forces the TAIT to show up in the type signature of the function so it can compile, though, so it's brilliant in that respect. Also, TIL where clauses with no bounds after the colon are legal. 😄

[h33p]

Is there any plans of stabilizing impl_trait_in_assoc_type anytime soon? Given #115822 being merged, I was excited to try those features out, however, it appears there is no way of using them without breaking API changes to the trait definitions (removing associated types and directly referring to impl Trait).

[GlenDC]

FYI for now I make use of async fn traits in a fork of Tokio's tower (https://github.com/plabayo/tower-async). However it turns out there are a lot of usability concerns. First of all the stabilisation of the async fn trait features in this and the upcoming rust versions mean not much given that for now there is still a need for the RTN (return type) notation for our use cases. On top of that there is no immediate plans to support dynamic dispatch for async fn traits. This means boxed services are also out (without a lot of awkward work arounds). A last ergonomic issue is that the resolver cannot always infer auto trait bounds correctly given awkward to impossible situations.

As such, to summarise, a lot of ergonomic problems.

In contrast, while syncing back with the tower team to see what they think of tower-async and what future direction we can take (breaking change) to easier (and without boxing) support opaque futures, the impl Trait notation in associated types came up. I played with this idea and described its results at tower-rs/tower#753 (comment), with playground https://play.rust-lang.org/?version=nightly&mode=debug&edition=2021&gist=11b0998956ab3ac077ec54a683d5c425.

The feature and RFC tracked in this issue works beautifully. It has none of the ergonomic pitfalls, requires no breaking changes in existing future code, in general plays very nice with Rust and the way it handles async code through futures. It just works. And thus dynamic dispatch is also possible, given we work with non async fn code here.

I discover this nightly feature late, but I feel that this feature (impl Trait as associated types in traits) should have been the feature being stabilised in the async story over others. As it really plays well with existing code and just works. Love it. To the future and beyond!

[rakshith-ravi]

Adding to @GlenDC's point - given that we already have AFIT, at the end of the day, AFIT anyway desugars to some form of impl_trait_in_assoc_type. So the implementation shouldn't be too different. I would strongly suggest stabilizing it since it would make using tower much easier to use un-boxed without having to change existing code

[Finomnis]

How far is this feature from stabilization? I'd love to see RTIC 2 on stable Rust :)

I'm asking because I don't see any major blockers in the task list, and want to ping so people don't forget about this feature :)

[h33p]

For people wondering, I asked on Zulip, and I was was told there are quite a few design blockers to be done. So no, it's not yet ready.

Related issues: https://github.com/rust-lang/rust/issues?q=is%3Aopen+is%3Aissue+label%3AF-type_alias_impl_trait++label%3AT-lang

[GlenDC]

Thanks for the updates. And honestly no rush, it takes as long as you need. I can wait.
My point was more that I feel that this RFC is a lot more useful then features that are about to be stable.
This due to mostly ergonomics, compatibility with existing code bases and the fact that for many real world scenarios there is still a need for awkward nightly features in order to use the soon to be stable features.

That said, take your time, thanks for everything and take care.

[vojtechkral]

Edit: I moved this question to the internals forum:

https://internals.rust-lang.org/t/rtn-aliases-as-a-simpler-alternative-to-taits-existential-types/20024

[RalfJung]

The impl Trait syntax is already overloaded for at least two semantically very different usecases

That's not true, impl Trait is always an existential type. Some people make a difference between argument position and return position but that's really not necessary.

(Discussing this in detail is off-topic here, I just felt it was important to point out this (common) misconception. :) Zulip or https://users.rust-lang.org/ would be a better place to discuss this.)

[vojtechkral]

Ok, I removed that part.