Rust's const generics team lays out Generic Const Args to replace generic_const_exprs

Serguey Asael Shinder04 October 2026, 12:442 min read

Rust's Const Generics project group has described the design that is meant to replace the long-unstable generic_const_exprs feature. A post on the Inside Rust blog on 2 October presents Generic Const Arguments, GCA for short, a family of nightly features that let more kinds of expressions involving generic parameters appear in const generic arguments. The design was first discussed at RustFest Zürich in June 2024.

The limit it addresses. On stable Rust a const generic argument can be a bare parameter such as { N } or a fully concrete expression such as { 1 + 1 }. Types like [u8; N + 1] or [u8; T::NUM_BYTES] are not possible, which, the post notes, pushes people towards the typenum crate.

What GCA adds. Every newly supported expression must be wrapped in a gca! macro.

• gca_adts allows constructing structs, enums, tuples and arrays from generic parameters, such as gca!(Foo { field: N }) or gca!([N1, 12]). Array repeat expressions like [N; 2] are not supported yet.
• gca_const_items lets const items be used in the type system, including associated constants ([u8; gca!(T::ASSOC)]) and generic free constants. Since a const item can contain arbitrary code, this indirectly allows arbitrary expressions: gca!(N + 1) is rejected, but const FOO: usize = N + 1; can be used. It also allows bounds such as T: Trait<ASSOC = { N }> and dyn types for traits with associated constants, both rejected on stable. It requires the unstable -Znext-solver.
• A const item whose right-hand side is itself a gca! expression is treated transparently, so the compiler can prove that [u8; FREE_GCA::<N>] and [u8; N] are the same type; an ordinary const item stays opaque and the same comparison fails.
• gca_min_const_items is a smaller version that only accepts const items defined by gca! expressions and does not need the new trait solver.

What it costs to write. Inside gca!, arithmetic and function calls are not allowed: gca!(1 + 1) is an error while { 1 + 1 } is not. The team says the macro requirement poses significant ergonomic problems and that it has not yet found a way to avoid it.

What it means

Nothing here is stable, and the post is a design explanation rather than a schedule. Its value for library authors is direction: the long-running generic_const_exprs experiment has a successor, and the route to computed array lengths will go through const items rather than arbitrary arithmetic written inline. Code built on typenum has no reason to move yet.