Decide about future of `rustc_legacy_const_generics`

[traviscross]

Back in 2021, we converted stdarch intrinsics to use const generics:

• Use const generics for stdarch intrinsics #83167

However, we seem to have left open the question of how strongly we want to deprecate rustc_legacy_const_generics and whether it's appropriate to use rustc_legacy_const_generics on new APIs.

Following guidance (in #83167 (comment)) related to the experience for people on older MSRVs, our documentation still points people toward this "legacy" syntax (e.g.).

On the other hand, we recently made this legacy syntax significantly less functional than the const generic equivalent in:

• Fix ICE when passing DefId-creating args to legacy_const_generics. #130443

Our discussion on that proceeded as follows (2024-10-30):

TC: This proposes to make an error out of:

std::arch::x86_64::_mm_blend_ps(loop {}, loop {}, foo::<3>());

...and similar cases that lean on legacy_const_generics.

This is not believed to break anything in practice and is being done for implementation reasons.

TC: This is marked as an easy decision for us. Do we agree?

Josh: We've thought about trying to make this a first-class feature. How difficult are the bugs in question to fix?

CE: If we ever wanted this as a first-class feature, we'd need to tear this out anyway and reimplement it. What's in the compiler now cannot architecturally support extending this feature more generally.

NM: We may in fact want this first-class feature. But I would want it to be approached as an equality constraint being introduced, not a "rewrite".

CE: It could certainly be done; just not how it was done.

TC: This is now in FCP.

For my part, I had taken from our decision and discussion that we mean to phase out as much as possible of what relies on the current implementation and concept of rustc_legacy_const_generics while at the same time being open to proposals for how we might approach this in a more appealing way. However, given the open questions we had left in 2021, it seems less clear to me now what our plan is.

Perhaps without noticing, we recently stabilized the AVX512 intrinsics with rustc_legacy_const_generics:

• Stabilize the avx512 target features #138940
• Tracking Issue for AVX512 intrinsics #111137
• Stabilize AVX512 intrinsics stdarch#1819

@RalfJung has proposed that, maybe, as this only went out in Rust 1.89, we could see about clawing this back. Conversely, there's a proposal, for consistently, to extend rustc_legacy_const_generics to all intrinsics with const generic parameters:

• Add #[rustc_legacy_const_generics] to all intrinsics with const-generic parameters stdarch#1916

What do we want to do? The questions for us include:

• Should rustc_legacy_const_generics be applied to new APIs? If not, should we mark it as "deprecated"?
  • rename rustc_legacy_const_generics to make it more clear that it is (soft) deprecated #146577
  • Tracking Issue for AVX512_FP16 intrinsics #127213
• Should rustc_legacy_const_generics be applied to existing APIs for consistency?
• Should we see if we can claw back rustc_legacy_const_generics from AVX512 intrinsics?
• Should we be lang FCPing the PRs for intrinsic stabilizations such as AVX512 so as to maybe catch this sort of thing? (We only FCPed the AVX512 target feature.)
• Should rustdoc be suggesting the legacy syntax or the const generic syntax to people?
• Do we have appetite to see about issuing FCWs or moving people off of rustc_legacy_const_generics over an edition?

cc @RalfJung @BoxyUwU @Amanieu @sayantn @rust-lang/project-const-generics @rust-lang/wg-const-eval @rust-lang/lang

[RalfJung]

FWIW I fully agree that ergonomically speaking, the legacy syntax is much nicer. OTOH, from what I understood, we currently can't really support syntax in the compiler where it is not syntactically obvious (before name resolution!) whether a term is a constant or a normal runtime expression. That's what leads to odd issues such as #130443. (Well, we do have promotion. But that has its own set of curses and the decision is made based on the expression itself, not its surrounding context.)

But what we have now is really strange -- an ad-hoc half-supported compiler hack with very special behavior seen nowhere else in the language that stdarch and nobody else gets to use.

[BoxyUwU]

More than just "before name res" it also only works in cross-crate scenarios- you can't use legacy const generics call syntax from within the same crate as the function.

While I do agree that its more ergonomic- that's really a thing for lang to go figure out how to make generic arguments more ergonomic. This is far from a problem with const generics, it's also annoying to turbofish type arguments.

I'm reminded of a convo a while ago in the T-lang zulip streams about a dedicated feature for "compile time function arguments" that was distinct from const generics. I can't remember what the outcome of that was.

[nbdd0121]

I think having const function arguments is desirable. This was heavily desirable feature that RfL want for example (e.g. for compile-time bound checking in https://rust.docs.kernel.org/kernel/io/struct.Io.html#method.write8). It is also something that we want for kernel atomics (for Ordering).

I'd wish if we evolve the language so that the "legacy" syntax becomes a new language feature.