Tracking Issue for non-lifetime binders

[compiler-errors]

This is a tracking issue for "non-lifetime binders" (rust-lang/types-team#81).
The feature gate for the issue is #![feature(non_lifetime_binders)].

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

• Initial implementation them
• RFC needs to be written
• Adjust documentation (see instructions on rustc-dev-guide)
• Stabilization PR (see instructions on rustc-dev-guide)

Unresolved Questions

None yet

Implementation history

• Implement partial support for non-lifetime binders #107489

[compiler-errors]

Having recently thoroughly reviewed the guidelines for experimenting with new feature gates (#109010 (comment) 😅), it dawned on me that that the T-types MCP that I did in rust-lang/types-team#81 may have been insufficient to justify landing experimental support for non-lifetime binders in the compiler...

Would anyone from @rust-lang/lang like to chime in here? Not exactly sure if it warrants a T-lang second + kicking off an FCP if we're trying to follow procedure, or if it's not worth it a month after landing the PR adding support. In any case, I'm trying to at least retroactively do my due dilligence here (and will do so for feature gates I add in the future in the future, sorry about that again lol).

Given the MCP from a T-types perspective, it's already confirmed that we on T-types would like to have non-lifetime binders support in the language for experimentation (especially given the pretty gnarly modifications to the trait solver that will be needed to get non-lifetime binders working fully), but if T-lang is not confident about this experimental feature (or would like an RFC), I guess I could un-land it as well. Let me know!

[nikomatsakis]

I'm happy to serve as a lang-team second here. I don't think we need to do the full MCP, but if anyone on @rust-lang/lang has concerns about the idea of supporting things like for<T>, please raise them now.

Just for good measure, I'll nominate for lang team triage meeting.

@rustbot labels +I-lang-nominated

[scottmcm]

To me, accepting GATs was a de-facto "yes, you can experiment with for<T>", since the parallels are so strong.

[nikomatsakis]

@rustbot labels -I-lang-nominated