Repository navigation
Decide about future of rustc_legacy_const_generics #146613
Description
Activity
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.
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.
Reacted by Josh TriplettI think having
constfunction 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 (forOrdering).I'd wish if we evolve the language so that the "legacy" syntax becomes a new language feature.
Reacted by Josh TriplettI think having
constfunction 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 (forOrdering).That's a really good point! Considering we want this for constants, I wonder to what extent a combination of a const function argument, an inline function, and
const ifor similar, would be sufficient to solve this?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.
Yeah, if we added something like
constfunction arguments, I'd expect that to require anything more complex than42orEnum::Variantto be put in an explicitconstblock.Reacted by GrigorenkoPVrustc_legacy_const_generics shouldn't be added to any newly added functions, we should go further and make it a hard error to rely on as a caller on newer editions. this syntax is more limited than actually providing the generic argument as a generic argument and is very much a backwards compatibility hack not a feature
If we lint against all uses of the attribute except those that are syntactically already constants (literals, paths, and
const { ... }blocks), would that work? Currently, aconstblock as such an argument does trigger the "invalid argument to a legacy const generic" lint; is that truly needed for something that's already clearly identifiable as a constant?
Back in 2021, we converted stdarch intrinsics to use const generics:
However, we seem to have left open the question of how strongly we want to deprecate
rustc_legacy_const_genericsand whether it's appropriate to userustc_legacy_const_genericson 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:
Our discussion on that proceeded as follows (2024-10-30):
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_genericswhile 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:@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_genericsto all intrinsics with const generic parameters:#[rustc_legacy_const_generics]to all intrinsics with const-generic parameters stdarch#1916What do we want to do? The questions for us include:
rustc_legacy_const_genericsbe applied to new APIs? If not, should we mark it as "deprecated"?rustc_legacy_const_genericsbe applied to existing APIs for consistency?rustc_legacy_const_genericsfrom AVX512 intrinsics?rustc_legacy_const_genericsover an edition?cc @RalfJung @BoxyUwU @Amanieu @sayantn @rust-lang/project-const-generics @rust-lang/wg-const-eval @rust-lang/lang