Tracking Issue for keyword generics

[oli-obk]

This is a tracking issue for https://github.com/rust-lang/keyword-generics-initiative
The feature gate for the issue is #![feature(keyword_generics)].

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

• Implement the RFC (@oli-obk is employed by aws to work on it, with regular reviews by @lcnr)
• Adjust documentation (see instructions on rustc-dev-guide)
• Stabilization PR (see instructions on rustc-dev-guide)

Unresolved Questions

Implementation history

• https://github.com/oli-obk/rust/tree/const_trait_take_two

[doivosevic]

whats the status of this?

[oli-obk]

This feature has been replaced by #110395

[FeldrinH]

This feature has been replaced by #110395

@oli-obk Did you link the wrong issue? #110395 is "Tracking Issue for removing impl const and ~const in the standard library". I don't see how that could possibly replace keyword generics.

[yoshuawuyts]

I think it's worth clarifying here that: yes, we're still working on effect generics. But to implement that in the compiler we first have to generalize the existing unstable ~const feature to be able to be used with other keywords too. And in order to do that, we have to first remove the existing integration of ~const from the stdlib. That's what #110395 is tracking:

This is a tracking issue for removing impl const and ~const in the standard library. This is carried out so that migrating to a new implementation under keyword generics can go more smoothly. See this Zulip thread for discussion around this operation.

Despite impl const and ~const being removed from the stdlib, they are still (experimentally) being developed as part of the language. The general tracking issue for this is the #[feature(effects)] gate. We expect that once the removal from the stdlib is complete, we'll be able to begin reworking the feature and probably gate + track features more granularly (ref):

The removal is supposed to make it so that it is easier to land the better implementation. Therefore, the procedure is removal -> better implementation -> restoration. Removing after the better implementation makes no sense, since we'd still want to continue to experiment const traits until stabilization of a better syntax.

@FeldrinH Does that make sense?