Tracking Issue for macroless_generic_const_args

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

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

• Implement the the feature under the min_generic_const_args feature (https://github.com/rust-lang/rust/pull/158617)
• Cut out the macroless part from min_generic_const_args, create a new macroless_generic_const_args feature (https://github.com/rust-lang/rust/pull/159058)
• Investigate community impact of "macroful" mGCA, see where needs and constraints are, do crater runs, etc.
• Relatedly, explore ideas for "the anon const fallback knife" (explained under "Unresolved Questions" below)
• 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

The logic of "attempt to lower as a directly represented argument, fall back to anon const if we can't" has several fairly sketchy aspects to it. There is a set of expressions that are allowed to be represented directly, and a set that isn't, and we need to cut these two sets apart somehow. How "sharp" this knife doing the cutting is, how fancy we get with it, etc., is an open question. Relevant topics:

• Potential behavior difference to inference (_) if represented directly or via anon const
• Whether we allow nameres to influence whether an expression is represented directly or falls back to an anon const, or if we require the decision to be made purely on syntax
  • for example, under min_generic_const_args, we could make paths to type consts be represented directly, but paths to regular consts fall back to anon consts
  • but if generic_const_args is enabled, we could make both paths to type consts and paths to regular consts be supported directly

Implementation history

• https://github.com/rust-lang/rust/pull/158617 initial implementation of the feature, still under the min_generic_const_args gate, not split out into its own feature yet
• https://github.com/rust-lang/rust/pull/159058 cutting out the macroless part into its own feature
• #162541 split out macroless applying to const items into a different feature gate

Start with the linked implementation PRs #158617 and #159058, then read the Unresolved Questions section and the rustc-dev-guide stabilization and documentation guidance. The remaining work is to investigate community impact, run crater experiments, clarify the anon-const fallback design, update documentation and style guidance, and complete stabilization.