Tracking issue for generic const items

[fmease]

This is a tracking issue for the experimental feature generic const items (RFC pending).
The feature gate for the issue is #![feature(generic_const_items)].

It enables generic parameters and where-clauses on free and associated const items.
See also rust-lang/lang-team#214.

About experimental features

An experimental feature is one that has not yet had an RFC. The idea is to allow implementation work to proceed to better inform an upcoming RFC. Experimental features cannot be stabilized without first having an RFC. The existence of an experimental feature does not indicate lang team consensus that the feature is desirable, only that there is a problem that is worthy of being solved and that the idea has enough merit to consider exploring. See the lang team process page for more details.

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 experiment: Implement generic const items #113522
• Write an RFC
• Should GCIs be evaluated at definition if they are lifetime generic
• Adjust documentation (see instructions on rustc-dev-guide)
• Formatting for new syntax has been added to the Style Guide (nightly-style-procedure)
• Formatting has been implemented in rustfmt according to the Style Guide
• Rustdoc JSON support has been added
• Stabilization PR (see instructions on rustc-dev-guide)

Experimental results

Part of the goal of the experimental process is to identify benefits but also concerns that need to be addressed in the RFC. This section catalogues notable findings thus far.

1. Do we want to require “where Self: 'a” bounds on GACs like we do on GATs (GATs: Decide whether to have defaults for where Self: 'a #87479)?
   Unresolved, not implemented.
2. Should #![feature(trivial_bounds)] const _UNUSED: () = () where String: Copy; successfully compile?
   Ideally yes, not implemented.
3. Should we forbid underscore identifiers for const items with generic parameters (e.g., const _<T>: () = ();)?
   Unresolved, not implemented.
4. Should we imply some outlives-bounds? E.g., should the presence of &'a &'b () in const K<'a, 'b>: &'a &'b () = &&(); imply the bound 'b: 'a (similarly, const K<'a, T>: &'a T = loop {}; and T: 'a)?
   Probably yes, not implemented.

Implementation history

• Implement generic const items #113522
• Don't crash when reporting nice region errors for generic const items #114758
• Improve diagnostic for generic params from outer items (E0401) #115744
• Introduce const Trait (always-const trait bounds) #119099
  • Among other things, this PR makes it possible to use const trait bounds in GCIs under CTI/effects
• Fix type resolution of associated const equality bounds (take 2) #119385
  • Among other things, this PR makes it possible to use GACs¹ in ACEs
• Generic associated consts: Check regions earlier when comparing impl with trait item def #123898
• Properly deal with missing/placeholder types inside GACs #125457
• GCI: Don't try to eval / collect mono items inside overly generic free const items #136168
• Emit user type annotations for free consts in pattern position #140548
• GCI: At their def site, actually wfcheck the where-clause & always eval free lifetime-generic constants #136429

Footnotes

1. Generic associated constants, i.e., associated constants with generics and/or a where clause. ↩

[ytmimi]

Making a note that there's an issue in rustfmt related to #![feature(generic_const_items)] rust-lang/rustfmt#5995.

Edit: The issue should be resolved by rust-lang/rustfmt#5996