Tracking Issue for macroless_const_item_generic_const_args

The feature gate for the issue is #![feature(macroless_const_item_generic_const_args)]. Using it requires #![feature(min_generic_const_args)] to be enabled as well.

Note: this tracking issue was largely copied from #159006 which was originally written by @khyperia

Background

On stable, there are two kinds of const arguments for generics at the moment:

• "anon consts", which cannot be generic, and support arbitrary expressions. These are opaque to the type system, and are blindly handed off to CTFE to get a concrete value for.
• min_const_generics arguments, which are plain paths to const parameters, used in e.g. array lengths (e.g. fn foo<const N: usize>(x: [u32; N]) {}). These are visible to, and reasoned about, by the type system.

The second category, things that can be reasoned about by the type system, have the (bikesheddable) name of a "directly represented" const argument. The generic_const_args family of features is about expanding and reasoning about these directly represented const arguments in various ways.

#![feature(min_generic_const_args)] extends the set of directly represented const arguments with:

• the direct_const_arg!() macro allows a significantly expanded set of expressions within it, e.g. paths to type const items, paths to regular const items, struct expressions, array expressions, so on and so forth. (Informational note: each of these can be and likely will be under various feature flags, e.g. paths to type const items are supported under min_generic_const_args, but paths to regular const items are only supported under generic_const_args)

Finally, we come to this feature, #![feature(macroless_const_item_generic_const_args)]. This feature extends the set of directly represented const arguments with:

• Anything that used to be supported within the direct_const_arg!() macro as the right hand side of a const item, is now supported without the macro. Expressions will be attempted to be lowered "directly", and if they cannot be represented directly, it will automatically fall back to being represented as an anon const.

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.
Discussion comments will get marked as off-topic or deleted.
Repeated discussions on the tracking issue may lead to the tracking issue getting locked.

Steps

• Adjust documentation (see instructions on rustc-dev-guide)
• Style updates for any new syntax (nightly-style-procedure)
  • Style team decision on new formatting
  • Formatting for new syntax has been added to the Style Guide
  • (non-blocking) Formatting has been implemented in rustfmt
• Stabilization PR (see instructions on rustc-dev-guide)

Unresolved Questions

• can we merge this back into #159006

Implementation history

Start by reading the feature-gate background and the linked rustc-dev-guide stabilization and documentation instructions. Track the implementation history and related issue #159006 before taking work. Done requires the documentation, syntax-style checklist, and stabilization PR steps to be resolved.