Tracking issue for const generics (RFC 2000)

[withoutboats]

Tracking issue for rust-lang/rfcs#2000

Updates:

• 2 May 2019: Tracking issue for const generics (RFC 2000) #44580 (comment)
• 19 Oct 2019: Tracking issue for const generics (RFC 2000) #44580 (comment)
• 2 Jan 2020: Tracking issue for const generics (RFC 2000) #44580 (comment)
• 22 Jul 2020: Tracking issue for const generics (RFC 2000) #44580 (comment)
• 17 Nov 2020: Tracking issue for const generics (RFC 2000) #44580 (comment)
• 11 Dez 2021: Tracking issue for const generics (RFC 2000) #44580 (comment)

If you want to help out, take a look at the open const generics issues and feel free to ping @varkor, @eddyb, @yodaldevoid, @oli-obk or @lcnr for help in getting started!

---

Blocking stabilization:

• Design:
  • Resolving ordering of const and type parameters, with default parameters
  • Decide what the best UX / implementation cost balance is for unifying abstract const expressions.
  • How we determine well formedness of const expressions.
• Implementation
• Documentation
  • rustc guide

---

Remaining implementation issues:

• Resolve various FIXME(const_generics) comments.
• Resolve concerns with canonicalisation / lazy normalisation.
• Investigate handling of const parameters in patterns.
• Add more tests.
• Implement defaults for const parameters (FIXME(const_generics_defaults)).
• Fix other A-const-generics issues.
• Audit uses of has_infer_types.
• Forbid complex expressions for const arguments involving parameters (for now), e.g. {X * 2}.
• Audit diagnostics (e.g. Add help note to unconstrained const parameter #76401 (comment)).

[eddyb]

#44275 added a ConstEvaluatable predicate, and WF([T; expr]) now requires ConstEvaluatable(expr), as expr is lazily evaluated (even if it's just an integer literal). Fulfilling this predicate requires the expression to evaluate successfully, while normalization ignores the error and simply leaves the Unevaluated expression it found, untouched, which is more or less what happens with associated type projections. I expect the same system to scale to const generics.

@EpicatSupercell has expressed interest in working on this, I'll mentor them through the initial implementation. However, we can't go too far because of the limitations described in #44275.

That is, we need @nikomatsakis' lazy normalization to allow constant expressions embedded in types to observe the bounds in scope (from the function / type definition / impl / etc. item they're in), without producing cyclic dependencies half the time.

[eddyb]

Implementation waypoints (for more direct mentoring, seek @eddyb on Gitter or eddyb on IRC):

• Declaration / Syntax:
  • Data structures: AST and HIR - add const parameters alongside type ones
  • Parsing: parse_generic_params - parse const IDENT: Type
  • Misc: visiting (AST, HIR), folding (AST), lowering (HIR), HIR map, DefId collector
• Declaration / Semantics
  • Data structures: ty::Generics - add const parameters alongside type ones
  • Conversion from HIR: generics_of - create ty::ConstParameterDef from hir::ConstParam
• Use / Name Resolution
  • Data structures: Def - add a variant for const parameters
  • Name resolution pass: with_type_parameter_rib - support both type and const generics
• Use / Semantics
  • ConstVal - add Param variant akin to ty::TyParam
  • Conversion from HIR: TyArray with a length that's an ExprPath that resolved to Def::ConstParam should use ConstVal::Param instead of ConstVal::Unevaluated - in a similar fashion to how Def::TyParam turns into ty::TyParam
  • subst::Kind - support &ty::Const and check as_const as well in where places where as_type and as_region are checked
• Inference
  • ConstVal - add InferVar variant akin to ty::ReVar / ty::TyInfer(TyVar(_))
  • InferCtxt - const counterparts to int_unification_table and its UnifyKey impl
  • ty::relate::{Relate,TypeRelation} - support relating ty::Const, and handle ConstVal::InferVar in a similar way to how super_combine_tys does it for types

Note that all of this should allow impl<T, const N: usize> Trait for [T; N] {...}, but not actually passing a constant expression to a type/function, e.g. ArrayVec<T, 3>.

[jplatte]

I'd like to take a stab at this :)

[samsartor]

@jplatte @eddyb Any news on this?

[jplatte]

@samsartor there was a refactoring that had to be done before the main implementation work. That is now almost done (I'm waiting for feedback currently). I don't actually know how much work there is after that. Parsing const params was what I started with initially, before the refactoring. It's not done but I should be able to get that done relatively soon.

[EdorianDark]

@jplatte It would be nice, if you could link the pull request. I was not able to find it.

[jplatte]

There is no PR yet. All my work can be found here.

[RobertWHurst]

Nice work so far @jplatte 🍻

[jplatte]

There is now a PR for the groundwork (Generics refactoring): #45930

[huhlig]

I think this is already included but it would be good to handle the C++ style folding for handling linear algebra style n dimensional arrays with varying lengths, I.E. a 4x4 [[f64;4];4]or a 4x3x5x6 dimensional array [[[[f64;6];5];3];4] and be able to properly wrap and generate specialized methods for both it AND proper trait implementations for scalars properly dimensioned vectors, etc. See https://gist.github.com/huhlig/8b21850b54a75254be4b093551f8c2cb for a rudamentary example.

[Ixrec]

I don't recall anyone proposing fold expressions for Rust before, much less as part of this RFC. But since this is Rust, is there any reason we couldn't implement fold expressions as an ordinary macro, rather than new dedicated syntax?

[mqudsi]

What I mean is, if you want to refactor typical parser code like the following for reuse:

let mut result: u32 = 0;
let mut digits = 0;
while digits < max_digits && src.has_remaining() {
    match src.get_u8() {
        d@b'0'..=b'9' => {
            result = result*10 + (d - b'0') as u32;
            digits += 1;
        },
        b'>' => match result {
            0..=191 => break, // valid range
            _ => return Err(DecoderError::OutOfRange),
        },
        _ => return Err(DecoderError::Malformed)
    }
}

You would typically move it out to a function, except the following won't work because certain values that are used in pattern matching have become variables:

#[inline(always)]
fn read_str_digits<B: bytes::buf::Buf>(src: &mut B, stop_word: u8, 
    max_digits: u8, min_value: u32, max_value: u32) -> Result<u32, DecoderError> {
    let mut result: u32 = 0;
    let mut digits = 0;
    while digits < max_digits && src.has_remaining() {
        match src.get_u8() {
            d@b'0'..=b'9' => {
                result = result*10 + (d - b'0') as u32;
                digits += 1;
            },
            stop_word => match result {
                min_value..=max_value => break, // valid range
                _ => return Err(DecoderError::OutOfRange),
            },
            _ => return Err(DecoderError::Malformed)
        }
    }

    ...
}

If const generics lands before const arguments, I can suddenly abuse const generics to come up with the following:

#[inline(always)]
fn read_str_digits<const MinValue: u32, const MaxValue: u32, const StopWord: u8, B: bytes::buf::Buf>
(src: &mut B, max_digits: u8) -> Result<u32, DecoderError> {
    let mut result: u32 = 0;
    let mut digits = 0;
    while digits < max_digits && src.has_remaining() {
        match src.get_u8() {
            d@b'0'..=b'9' => {
                result = result*10 + (d - b'0') as u32;
                digits += 1;
            },
            StopWord => match result {
                MinValue..=MaxValue => break, // valid range
                _ => return Err(DecoderError::OutOfRange),
            },
            _ => return Err(DecoderError::Malformed)
        }
    }

    ...
}

As of today, even this code won't work because the compiler does not detect the const generic values to be constants valid for use in a pattern, but that is obviously incorrect and needs to be addressed before RFC 2000 can land. Don't get me wrong, I've been fighting for generic constants for years and I have PRs ready to go for a dozen major crates (I can't wait to make the timezone in chrono a const generic and unify all the various DateTime types), but imho if it becomes possible to abuse const generics to fake const arguments (where by "const" what we really mean is "literal") then you're going to see widespread abuse of that.

It's not necessarily the end of the world, but without having dug too deeply into it, it does seem as if a proper and complete const generics implementation will necessarily include all the plumbing for const arguments anyway, so we might as well take the extra time to finalize the syntax/ux/story for const arguments while we're at it and avoid an unfortunate era of code stink. Yes, the above can still be done with macros, but the ergonomics of const generics are a thousand times easier.

fwiw, this is how I'd imagine the const argument version to look like:

#[inline(always)]
fn read_str_digits<B: Bytes>(src: &mut B, min_value: const u32, 
    max_value: const u32, stop_word: const u8, max_digits: u8) -> Result<u32, ()> {
    let mut result: u32 = 0;
    let mut digits = 0;
    while digits < max_digits && src.has_remaining() {
        match src.get_u8() {
            d@b'0'..=b'9' => {
                result = result*10 + (d - b'0') as u32;
                digits += 1;
            },
            stop_word => match result {
                min_value..=max_value => break, // valid range
                _ => return Err(()),
            },
            _ => return Err(())
        }
    }

    ...
}

It would virtually be identical to const generics but for the semantics.

[varkor]

You would typically move it out to a function, except the following won't work because certain values that are used in pattern matching have become variables:

This seems like a use-case that is more readily addressed by allowing the values of bound variables to be used in patterns (not just consts), with some new syntax. The fact that consts are currently allowed in patterns is counter-intuitive and, as far as I'm aware, historical.

[mark-i-m]

@mqudsi Forgive me if this is a silly question, but I don't see anything wrong about the example you gave. It looks like a perfectly valid use case for const generics to me: having a definition that is generalized to work with arbitrary values as the max/min. I don't really see the benefits of const arguments over const generics. They seem equivalent to me; that is, const arguments could just be implemented as a desugaring to const generics. Could you elaborate more on what's wrong with this design pattern?

[varkor]

Here's a summary of the work on const generics since the last update. Last time, it was all about the core implementation: making sure everything fitted together and getting some of the basic test cases passing. Since then, the effort has been focused on making const generics more reliable: fixing cases that crashed the compiler, or didn't work unexpectedly, or improving diagnostics. We're getting closer to something that works reliably, though there's still a way to go.

---

• @Skinny121 has been doing fantastic work in the last month fixing various outstanding issues with const generics:
  • Expanding the test suite (Add tests for concrete const types #60550)
  • Fixing type inference issues (Infer consts more consistently #64679, Changed resolve_type_vars_with_obligations to also resolve const inference variables #65579)
  • Supporting more types in const generics, including strings and slices (Add support for relating slices in super_relate_consts #64858) and pointers (Function pointers as const generic arguments #64986) (though note that these are likely not to be stabilised immediately alongside the rest of const generics, as they're not supported in the original RFC)
  • Fixing diagnostic issues with const generics (Fix const generic arguments not displaying in types mismatch diagnostic #65154, Changed resolve_type_vars_with_obligations to also resolve const inference variables #65579)
  • Fixing a number of issues with use of const generics cross-crate (Include const generic arguments in metadata #65365)
• @eddyb fixed some issues with const evaluation affecting const generics (rustc_mir: fix miri substitution/"universe" discipline. #63497)
• @matthewjasper fixed some issues with using const generics in macros (Make generic parameters always use modern hygiene #63083)
• @davidtwco fixed an issue involving const generics and constructors (Fix ICE with struct ctors and const generics. #60839)
• @GuillaumeGomez fixed the display of const generics in Rustdoc (Fix slice const generic length display #61605)
• @varkor fixed some type inference issues (Fix issues with const argument inference #61570, Allow const parameters in array sizes to be unified #60742, Fix substs issues for const errors #60508), an issue restricting the places const generics could be used (Fix a bug preventing const parameters from being used in const generic impls #60717) and various compiler crashes (Fix some issues with unwrap_usize instead of assert_usize #61380, Fix ICE with APIT in a function with a const parameter #61333, Use delay_span_bug for error cases when checking AnonConst parent #60710)

Additionally, other work on the compiler ended up fixing some of the other issues relating to const generics.

We've also started using const generics inside the compiler itself: array trait implementations now use const generics thanks to the work of @crlf0710 and @scottmcm (#60466, #62435), which led to performance improvements, and which will also allow us to unrestrict array trait implementations in the future (when const generics is stabilised). @Centril used the same approach to improve VecDeque (#63061).

---

Many of the particularly common bugs with const generics have been fixed in the past few months. @nikomatsakis is investigating lazy normalisation, which should fix a host of the remaining issues, while @jplatte is looking into fixing the disambiguation of const parameters from type parameters (so you'll no longer have to type {X} for a const argument).

I also want to thank @eddyb for all their mentoring and reviewing for const generics throughout development, which has been invaluable.

There are still quite a number of other issues to address and, as before, we could use all the help we can get — if you're interested in tackling any of the remaining issues, feel free to ping me on the issue, or on Discord or Zulip for pointers on getting started.

[bstrie]

I would like to request that we reserve the discussion of such a significant syntactic change for either a thread on internals or an issue (or amending PR) on the RFCs repo. This issue's comment section is already quite long and the syntax in question seems unnecessary for a usable MVP of const generics.

[eddyb]

If we could move comments we probably would. We might want to lock the issue to @rust-lang team members and hide all the offtopic comments?

All design discussion should happen on the RFC repo and all bug reports should be in separate issues.

cc @rust-lang/moderation Is there precedent for doing this?

[Manishearth]

You can convert a comment to an issue, but not move comments. Locking is fine, and i'd just hide off topic comments.

[varkor]

With the start of the new year, I thought it would be good to give another update on where we are now with const generics. It's been a little over 2 years since the const generics RFC was accepted. In the first year (roughly 2018), a series of large refactoring efforts were undertaken to facilitate const generics by improving the handling of generic parameters generally throughout the compiler. In the second year (roughly 2019), work began on implementing const generics itself: first by getting the bare minimum working, and then by slowing improving the integrity of the feature. People also started to experiment with using const generics in the compiler itself. More detailed descriptions of these efforts are in the first two update posts: [1], [2].

---

There's been good progress in the last couple of months since the last update.

• @Skinny121:
  • Fixed an issue breaking const generics under incremental compilation and across crates (Fix canonicalize_const_var leaking inference variables #65652)
  • Fixed a bug with type inference affecting const generics in diagnostics (Changed resolve_type_vars_with_obligations to also resolve const inference variables #65579)
  • Refactored the interface for const evaluation (Add simpler entry points to const eval for common usages. #66877)
• @yodaldevoid implemented disambiguation of type and const parameters so that const parameters no longer need to be wrapped in {} (Generic arg disambiguation #66104)
• @eddyb fixed the use of const generics as array lengths, once lazy normalisation is implemented (rustc_typeck: gate AnonConst's generics on feature(const_generics). #66883)
• @varkor:
  • Implemented structural_match checking to forbid types with custom equality checking from being used as const generics (Forbid non-structural_match types in const generics #65627)
  • Corrected some diagnostics to take const generics into account (Improve error message for APIT with explicit generic arguments #65614)
  • Performed various refactoring and type inference fixing (Correct handling of type flags with ConstValue::Placeholder #65643, Rename ConstValue::Infer(InferConst::Canonical(..)) to ConstValue::Bound(..) #65660, Fix an issue with const inference variables sticking around under Chalk + NLL #65696)

A big thanks to everyone who has been helping out with const generics!

---

What's next? The biggest blocker for const generics at the moment is lazy normalisation, which is required for certain kinds of const generic bounds (such as in arrays). @Skinny121 is currently investigating lazy normalisation, continuing their fantastic efforts taking down the big bugs in const generics. This would address many of the present issues with const generics.

Lazy normalisation aside, there are still a sizeable number of bugs and papercuts we'd like to address. If you're interested in tackling any of the remaining issues, feel free to ping me on the issue, or on Discord or Zulip for pointers on getting started. I'm confident we can make good headway in 2020 and hopefully approach a point where stabilisation becomes a viable discussion!

[withoutboats]

Is there a subset of const generics that doesn't hit lazy normalization and doesn't have many bugs and papercuts, but which can express a good amount of useful code? I notice that std's impls of many traits for arrays seem to work just fine. Maybe there's a narrowing that would allow other crates to write the kind of impls we have in std for their own traits, even though they don't support all the fancier functionality?

[varkor]

We're now more than halfway through the year, so I'll briefly summarise the work that has been going on. There have been lots of people involved in improving const generics support in the last 6 months, so thank you to everyone who's helped in some way! I especially want to thank @Skinny121 and @lcnr, who have both tackled some large features that const generics has been lacking for a while: lazy normalisation for constants and const argument support in method calls, as well as fixing numerous difficult bugs. Their efforts are evident from the summary below.

Const generics is now being used in several places throughout the compiler, and there's already experimentation with traits and functions making use of const generics, e.g. slice::array_chunks and IntoIterator and FromIterator for [T; N] (#65819, #69985). The length 32 restriction for array trait implementations is also finally being prepped for removal.

We're currently discussing stabilising a subset of const generics that should cover a wide range of use cases (though there are still some issues left to address before const generics can be fully stabilised).

---

• @Skinny121:
  • Implemented the first version of lazy normalisation (Canonicalize inputs to const eval where needed #68505, Change const eval to just return the value  #69181, Turn const eval queries into canonical queries #67717, Lazy normalization of constants #67890)
  • Improved performance (perf: Eagerly convert literals to consts #68118)
  • Fixed various errors (Forbid elided lifetimes within const generic parameter types #68143)
• @lcnr:
  • Added support for explicit const generics in type arguments for methods (Support const args in type dependent paths (Take 2) #74113)
  • Completed the first implementation of lazy normalisation for constants (Lazy normalization of constants (Reprise) #71973) with @Skinny121
  • Added a lint for unused_braces (add unused_braces lint #70081)
  • Fixed issue with const generics in patterns (infer array len from pattern #70562)
  • Forbade dyn Trait for const generic parameters (forbid dyn Trait in patterns #71038)
  • Improved pretty-printing (display ConstKind::Param #72052)
  • Fixed various errors (put type params in front of const params in generics_of #70032, WF-check all ty::Const's, not just array lengths. #70107, fix type of const params in associated types. #70223, handle ConstKind::Unresolved after monomorphizing #70249, correctly handle const params in type_of #70284, correctly normalize constants #70319, prohibit_generics: update has_err for consts #70541, correctly handle uninferred consts #72066, forbid generic params in the type of const params #74159)
  • Refactoring (Refactor type_of for constants #70478)
  • Added tests (const generics triage #74392, add test for #62878 #74445)
• @eddyb:
  • Fixed issues with const generics in array lengths (typeck: always expose repeat count AnonConsts' parent in generics_of. #70452)
  • Improved pretty-printing (ty/print: pretty-print constant aggregates (arrays, tuples and ADTs). #71232)
  • Improved error handling (Add ConstKind::Error and convert ErrorHandled::Reported to it. #71049)
  • Refactoring (ty/walk: iterate GenericArgs instead of Tys. #70164)
• @Aaron1011: fixed error with cross-crate const generics usage (Properly encode AnonConst into crate metadata #72600)
• @petrochenkov: fixed issues with name resolution and const generics (resolve: Fix two issues in fresh binding disambiguation #70006)
• @yodaldevoid: fixed an issue with lifetime use in const generic parameters (disallow non-static lifetimes in const generics #74051)
• @contrun: fixed an ICE (fix #62456 #69859)
• @oli-obk: refactoring (Evaluate repeat expression lengths as late as possible #69981)
• @Centril: improved diagnostics (Move arg/constraint partition check to validation & improve recovery #70261)
• @DutchGhost: added a test (add test for 62220 #70539)
• @varkor:
  • Improved pretty-printing (Fix ICE in const pretty printing and resolve FIXME #67909, Print constants in type_name for const generics #68111)
  • Fixed various errors (Silence TooGeneric error #67906, Make TooGeneric error in WF checking a proper error #68388, Move generic arg/param validation to create_substs_for_generic_args to resolve various const generics issues #68434)
  • Improved diagnostics (Make the structural_match error diagnostic for const generics clearer #70845)
  • Added tests (Add regression test for integer literals in generic arguments in where clauses #68312, Add two const generics regression tests #70939)

---

While const generics has already come a long way, there are still bugs and sharp edges. If you're interested in tackling any of the remaining issues, feel free to ping me, @lcnr or @eddyb on the issue, or on Zulip, for pointers on getting started. Thank you!

[lcnr]

Now that we're looking to stabilize #![feature(min_const_generics)] in #79135 let's once again summarize all the amazing work that's been going on since the last update. A lot of new people have come and helped out with getting #![feature(min_const_generics)] ready for stabilization as well as improving other parts of const generics. A huge thanks to everyone who spend their valuable time helping out here, no matter how small your contributions might have been!

I want to use this comment to especially highlight and thank @varkor! They not only fixed some large and complicated issues but also do a lot of less visible work by mentoring and helping others as well as collecting and triaging the remaining issues. While so many amazing people are responsible for where we are now, I do not believe this would have been possible without @varkor.

On other news, with #74060 now being merged, many traits are now implemented for arrays of any size, greatly improving the experience of working with them. This is available on stable since version 1.47 🎉

---

• @JulianKnodt:
  • Allowed const parameters to precede type params (Remove restriction on type parameters preceding consts w/ feature const-generics #74953)
  • Added fn array_windows (Add array_windows fn #75026)
  • Added array lang item and fn map to arrays (Add array lang item and [T; N]::map(f: FnMut(T) -> S) #75212)
  • Clarified error message for unconstrained const parameters (Add help note to unconstrained const parameter #76401)
  • Extended existing tests for min_const_generics (Add a bunch of const-generic revisions for min_const_generics #75322)
  • Added tests for min_const_generics (Add regression test for #72787 #75165, Add regression test for #64494 #75166, MinConstGenerics UI test for invalid values for bool & char #78428)
  • Fixed ICE for a cycle caused by const generics (Fix Const-Generic Cycle ICE #74199 #74991)
• @hameerabbasi:
  • Improved error message for type params in consts (Change error message for ty param in const #76719)
  • Extended existing tests for min_const_generics (Add revisions to const generic issue UI tests. #76514, Finish off revisions for const generics UI tests. #76599)
  • Added tests for async/await with const generics (Add test for async/await combined with const-generics. #77331)
  • Added tests for supertraits and trait objects (Add const generics tests for supertraits + dyn traits. #78478)
• @ethanboxx:
  • Improve diagnostics for forbidden usage of generic params (min_const_generics diagnostics improvements #77825)
  • Added tests for disallowed default values (Test default values for const parameters. #78960)
• @Amjad50
  • Implemented the incompatible features error (added a lint against function item references #76269)
  • Extended existing tests for min_const_generics (Added some min_const_generics revisions into const_generics tests #75938)
• @kpp:
  • Removed the LengthAtMost32 bound on array impls (Remove trait LengthAtMost32 #74060)
• @davidtwco:
  • Forbade lifetimes in consts for min_const_generics (resolve: prohibit anon const non-static lifetimes #76739)
• @pubfnbar:
  • Implemented Index and IndexMut for arrays (Implement Index and IndexMut for arrays #74989)
• @Mark-Simulacrum:
  • Allowed bool in symbol mangling (Permit ty::Bool in const generics for v0 mangling #77452)
• @varkor:
  • Improved parse errors for missing braces in const args (Suggest that expressions that look like const generic arguments should be enclosed in brackets #77502)
  • Adjusted turbofish help message (Adjust turbofish help message for const generics #78460)
  • Fixed issue regarding ConstKind::Placeholder (Add type to ConstKind::Placeholder #78463)
  • Extended symbol mangling for signed integers and char (Support signed integers and char in v0 mangling #77554)
  • Fixed diagnostics for impl Trait, added tests (Fix missing diagnostic span for impl Trait with const generics, and add various tests for min_const_generics and const_generics #77439)
• @lcnr:
  • Implemented min_const_generics restrictions (Implement the min_const_generics feature gate #74877, Forbid generic parameters in anon consts inside of type defaults #74487, allow concrete self types in consts #76195, min_const_generics: allow ty param in repeat expr #78224)
  • Added fn array_chunks (add slice::array_chunks to std #74373)
  • Dogfooded const generics inside of the compiler (use array_windows instead of windows in the compiler #76825)
  • Added tests (add const generics array coercion test #74671, add dropck test for const params #78985, extend min_const_generics param ty tests #78987, add explicit test for const param promotion #78996, extend const generics test suite #78916)
  • Improved error messages (improve const infer error #76699, improve const infer error #78249, improve type const mismatch errors #79032)
  • Fixed various bugs (fix unification of const variables #74040, correctly deal with unsorted generic parameters #74676, handle ConstEquate in rustdoc #74891, move const param structural match checks to wfcheck #75069, rustdoc: fix min_const_generics with ty::Param #76297, do not ICE on bound variables, return TooGeneric instead #76581, dead_code: look at trait impls even if they don't contain items #77073)
  • Started work on supporting generic const operations (Tracking Issue for complex generic constants: feature(generic_const_exprs) #76560)

While they have not opened any pull requests themselves since the last update, I also want to thank @petrochenkov, @nikomatsakis and @oli-obk for reviewing and helping with many of the more complicated changes seen above.

---

While we have come a long way over the last 3 years, this is still far from over. Even just for #![feature(min_const_generics)] there will always be diagnostics to add, bugs to fix and performances to improve. Looking a bit further into the future, there is even more work to do, some of which is explored in the future work section of #79135. If you are interested in helping out with any of this, feel free to either join the project group on zulip, comment on the relevant issues or directly reach out to either me or @varkor.

[lcnr]

A year has passed and we're finally stabilizing the next feature related to const generics:

✨ feature(const_generics_defaults) ✨

With this, I am going to once again summarize the progress made here. This summary was written by @lcnr and therefore overrepresents parts I have been involved with while not giving other areas the focus they deserve.

Generic const arguments

Soon after the stabilization of feature(min_const_generics) we started to focus on supporting generic expressions as const arguments. While doing so, we encountered quite a few major obstacles, because of which @rust-lang/project-const-generics started to have some weekly meetings in February. The current status can be tested using #![feature(generic_const_exprs)].

While we believe that we now know most of the remaining blockers, we also know that these are sadly very difficult to deal with.
Because of this, feature(generic_const_exprs) is still really far away from stabilization. @BoxyUwU and I recently discussed a potential #[feature(min_generic_const_exprs)] which can be more easily stabilized while still allowing computations in generic const arguments.

We still have to take these ideas to the rest of @rust-lang/project-const-generics, but there should hopefully be some news about this during the next year.

^{as the work on this feature has been greatly influenced by me experiencing burnout, here's a quick reminder that you should take regular breaks from any open source work you might do. always being available is incredibly unhealthy and is not desirable or praiseworthy}

Valtrees

Right now, constant values used as arguments for const parameters are represented using "allocations", this makes checking them for equality somewhat difficult, as comparing allocations directly does not consider two different &3 to be equal to each other and causes some other annoyances.

To deal with this, we (mostly @oli-obk and @RalfJung) introduced the concept of valtrees, which represents constant values in the type system as simple trees with integer leaves. Checking equality of valtrees is fairly trivial and using them avoids some other, more subtle issues as well. @oli-obk started to implement this in #82936 and while progress has recently stalled due to a lack of time, this is definitely something to look forward to.

Const parameter defaults

In #75384 @JulianKnodt began implementing const parameter defaults, with the initial PR taking more than 7 months and racking up a total of over 200 comments. Using this as a starting point, fixing the remaining issues was fairly straightforward, allowing us to stabilize this feature in #90207.

Generic arguments in patterns

After stabilizing feature(min_const_generics) in #79135, @CraftSpider opened #80531, showing that specifying the argument for const parameters in patterns is not supported. To my knowledge, nobody noticed this before, which is especially worrying considering that const generics was already stable on nightly at that time. The PR which fixed this is #80551.

match Some(Default::default()) {
   Some::<u8>(a) => assert_eq!(a, 0),
   None => {}
}

The same issue also existed for trait methods with incorrect const parameter types which has been fixed in #86843.

This shows that even though const generics has been used a lot while unstable and we took a lot of effort to improve our test coverage before stabilizing feature(min_const_generics), there were still some pretty simple bugs we've missed.

Pull Requests

Finally, an overview of most pull requests related to const generics which have been merged since the last update. As const generics is now stable and "infects" large parts of the compiler, and const parameters are fairly frequently used, there are many changes related to const generics which I did not mention here.

The decisions on which PRs to mention and which ones to ignore were made in mere seconds and are not well thought out. There are also changes I've simply missed while searching for them. If you see a pull request which should be mentioned here please either edit this comment yourself or pm me on zulip.

While this does highlight people working with and on const generics, there are many people whose contribution to const generics is not reflected below. Thank you to everyone who contributed.

• @Amanieu Add #[rustc_legacy_const_generics] #82447
• @b-naber Postpone the evaluation of constant expressions that depend on inference variables #90023 Prevent duplicate caller bounds candidates by exposing default substs in Unevaluated #90266 Prevent type flags assertions being thrown in default_anon_const_substs if errors occurred #90396 Skip reborrows in AbstractConstBuilder #90529
• @BoxyUwU const_evaluatable: expand abstract consts in try_unify #81426 const_evaluatable: consider sub-expressions to be evaluatable #81577 GAT/const_generics: Allow with_opt_const_param to return GAT param def_id #81911 const_generics: Dont evaluate array length const when handling errors #82009 const_generics: Fix incorrect ty::ParamEnv::empty() usage #82067 const_generics: Dont evaluate array length const when handling yet another error  #82112 Use correct param_env in conservative_is_privately_uninhabited #82159 const_evaluatable_checked: Stop eagerly erroring in is_const_evaluatable #82707 Fix generic arg mismatch errors being ignored with explicit late bound lifetimes #84410 Make const_generics_defaults not an incomplete feature #85251 Fix some diagnostic issues with const_generics_defaults feature gate #85800 Add test for forward declared const param defaults #85896 Display defaults on const params- rustdoc  #85957 const_eval_checked: Support as casts in abstract consts #86130 rustdoc- dont ICE on ConstEvaluatable predicates #86242 dont provide fwd declared params to cg defaults #86580 Make SelfInTyParamDefault wording not be specific to type defaults #87134 permit drop impls with generic constants in where clauses #87770 correctly handle enum variants in opt_const_param_of #87854 Add tests for some feature(const_evaluatable_checked) incr comp issues #88146 canonicalize consts before calling try_unify_abstract_consts query #88166 Add tests for some const generics issues #88602 generic_const_exprs: use thir for abstract consts instead of mir #88709 dont .ensure() the thir_abstract_const query call in mir_build #89113 Add some tests for const_generics_defaults #90114 Stabilise feature(const_generics_defaults) #90207
• @bstrie Stabilize impl From<[(K, V); N]> for HashMap (and friends) #84111 Replace Copy/Clone compiler magic on arrays with library impls #86041
• @c410-f3r Add 'core::array::from_fn' and 'core::array::try_from_fn' #75644
• @camelid Fix typo in error message #84141 rustdoc: Box GenericArg::Const to reduce enum size #88574
• @cjgillot GenericParam does not need to be a HIR owner. #83424
• @cuviper Cautiously add IntoIterator for arrays by value #84147
• @davidtwco passes: prohibit invalid attrs on generic params #79073
• @eddyb rustc_symbol_mangling: support structural constants and &str in v0. #87194
• @eopb AbstractConst private fields #88644
• @estebank Account for incorrect impl Foo<const N: ty> {} syntax #85346
• @FabianWolff Check the number of generic lifetime and const parameters of intrinsics #86148 Check that const parameters of trait methods have compatible types #86843 Fix handling of hir::GenericArg::Infer in wrong_number_of_generic_args.rs #88949
• @inquisitivecrystal Stabilize [T; N]::map() #87174
• @jakevossen5 fixed const_generics error help #80714
• @jethrogb Implement split_array and split_array_mut #83233
• @JohnTitor Run full const-generics test for issue-72293 #86205 Fix const-generics ICE related to binding #86795
• @JulianKnodt implement feature(const_generics_defaults) #75384 Add error message for private fn #79291 Add check for [T;N]/usize mismatch in astconv #80538 Add better diagnostic for unbounded Abst. Const #81544 Add diagnostics for specific cases for const/type mismatch err #82055 Allow using -C force-unwind-tables=no when panic=unwind #83482 Add hir::GenericArg::Infer #83484 Add help message to suggest const for unused type param #84784 Move generic error message to separate branches #89317
• @klensy simplify validate_generic_param_order #86185
• @lcnr extend WithOptConstParam docs, move rustdoc test #78609 const_generics: assert resolve hack causes an error #79236 correctly deal with late-bound lifetimes in anon consts #79298 const_evaluatable_checked: fix occurs check #79635 always eagerly eval consts in Relate #81309 combine: stop eagerly evaluating consts #81351 add const_evaluatable_checked test #81430 const_evaluatable: stop looking into type aliases #81433 update array missing IntoIterator msg #82626 extract ConstKind::Unevaluated into a struct #83040 various const parameter defaults improvements #84299 deal with const_evaluatable_checked in ConstEquate #85481 only check cg defaults wf once instantiated #86987 lazily "compute" anon const default substs #87280 update const generics feature gates #88369 small const generics cleanup #88557 add const generics test #90578
• @lqd In which we start to parse const generics defaults #80547 const_generics_defaults: don't ICE in the unimplemented parts #80599
• @mendess Add note to use nightly when using expr in const generics #79374
• @michaelwoerister Improve debug symbol names to avoid ambiguity and work better with MSVC's debugger #85269
• @MingweiSamuel Fix typo in const_generics replaced with adt_const_params note #88726
• @m-ou-se Update array_into_iter lint for 1.53 and edition changes. #85682
• @oli-obk Implement (but don't use) valtree and refactor in preparation of use #82936 normalize mir::Constant differently from ty::Const in preparation for valtrees #83207
• @osa1 Fix turbofish recovery with multiple generic args #82579
• @Patryk27 Rework diagnostics for wrong number of generic args (fixes #66228 and #71924) #77524
• @RalfJung Remove rustc_args_required_const attribute #85110
• @rylev A slightly clearer diagnostic when misusing const #79697
• @SimonSapin Stabilize by-value [T; N] iterator core::array::IntoIter #80470
• @Soveu Builtin derive macros: fix error with const generics default #84243
• @Stupremee suggest turbofish syntax for uninferred const arguments #77758
• @terrarier2111 Fix AnonConst ICE #91312
• @tmiasko Support building clone shims for arrays with generic size #79272 Remove FixedSizeArray #84094
• @varkor Permit standalone generic parameters as const generic arguments in macros #79164
• @yanok Use is_global in candidate_should_be_dropped_in_favor_of #90375

[joshtriplett]

Thanks to @lcnr for the ongoing excellent summaries!

[lcnr]

All remaining const generics features are tracked in separate issues:

• Tracking Issue for complex generic constants: feature(generic_const_exprs) #76560
• Tracking Issue for more complex const parameter types: feature(adt_const_params) #95174
• Tracking Issue for _ as a const argument: feature(generic_arg_infer) #85077

For more than 2 years now this issue has been pretty much exclusively used for update posts by either @varkor or myself. I intend to keep posting these updates but don't think this issue is necessarily the right place for them. I currently intend to post them to the Inside Rust blog, but I will try to link to the first of these posts here once the time has come.

Once again a huge thanks to everyone who has contributed to const generics over the last 5 years.