Repository navigation
Use const generics for array Default impl #61415
Description
Activity
- addedT-langRelevant to the language teamRelevant to the language teamT-libs-api[DEPRECATED; DO NOT USE][DEPRECATED; DO NOT USE]T-compilerRelevant to the compiler team, which will review and decide on the PR/issue.Relevant to the compiler team, which will review and decide on the PR/issue.A-const-genericsArea: const generics (parameters and arguments)Area: const generics (parameters and arguments)
on May 31, 2019 - addedC-tracking-issueCategory: An issue tracking the progress of sth. like the implementation of an RFCCategory: An issue tracking the progress of sth. like the implementation of an RFC
on May 31, 2019 As I noted in #60466 (comment) and #60466 (comment) I will not sign off on using const generics in stable Rust until such time that const generics are stable. However, we can provide unstable wrapper types meanwhile.
Reacted by Elichai TurkelReacted by Geoffry Song, krircc, Hameer Abbasi, Gurwinder Singh and Hellzbellz123We can probably both keep the exact observable behavior (impls for 0-32) and reduce metadata bloat by using a trick similar to #60466 (comment) (an empty marker trait implemented using macros + the real impl using const generics and a
whereclause with the marker trait).This way const generics would be an implementation detail, so their stabilization wouldn't be required.
Reacted by Hadrien G., Wesley Wiser, DutchGhost, Jacob Greenfield, scottmcm, est31, cynecx, Jake Goulding, krircc, Geordon Worley and 6 moreThe results from the crater run and perf run for using const generics for array impls are in (#60466).
cargo checkperformance is increased: Switch libcore array implementations to const generics. #60466 (comment). Otherwise, unchanged.- No regressions: Switch libcore array implementations to const generics. #60466 (comment). (Actually fixes a couple of crates that were relying on impls for larger arrays 😄)
I think there's good reason to go with @petrochenkov's suggestion (#61415 (comment)) and potentially consider lifting the restriction for array sizes.
does T-compiler actually need to be tagged on this issue? Unless its exposing bugs for const generics themselves, I would think this is solely a T-libs issue, maybe T-lang, but not T-compiler?
This libs team discussed this yesterday and agreed that we do not want to expand the stable surface API of the standard library, but changing implementaitons to use const generics seems fine so long as it doesn't expand the surface area of what's exposed (e.g. via @petrochenkov's idea)
Reacted by Mazdak Farrokhzad, tesuji, Mateusz Mikuła, qwerty19106, Jacob Greenfield, Masaki Hara, Dmitry Rusakov, Andre B. Reis, runiq, est31 and 5 moreReacted by Mathspy, Eduard-Mihai Burtescu and Gurwinder SinghThe @rust-lang/lang team discussed this and we agree with the libs team. =)
Reacted by Jacob Greenfield, runiq, Eduard-Mihai Burtescu, mosh and Denis KotlyarovReacted by Mathspy, tesuji and Eduard-Mihai BurtescuNo-expanded-surface area (#61415 (comment)) PR up at #62435
53 remaining items
- removedproposed-final-comment-periodProposed to merge/close by relevant subteam, see T-<team> label. Will enter FCP once signed off.Proposed to merge/close by relevant subteam, see T-<team> label. Will enter FCP once signed off.disposition-mergeThis issue / PR is in PFCP or FCP with a disposition to merge it.This issue / PR is in PFCP or FCP with a disposition to merge it.
on Sep 17, 2025 We talked about this question -- using const generics for the
Defaultimpl on arrays and supporting the unconditional[T; 0]: Defaultas a special case (for now) -- in the lang call today. We had appetite for seeing this happen. Please nominate the stabilization PR for us, and we'll FCP that along with libs-api.One thing we talked about is how arrays are already a bit magical, e.g. in how
[x; N]for somex: Tworks forN < 2even whenT: ?Copy, how constants are instantiated and droppedNtimes, etc. The magic needed forDefaultdoesn't feel categorically different than that.@nikomatsakis in particular mentioned that there are seemingly many routes open to being able to generalize this and that he wasn't worried about finding coherent and feasible design options. Whether any of those options would carry their weight, at the end of the day, as compared with just accepting the special case here, is something we don't know yet and would need to work out.
Reacted by David Tolnay, Jiahao XU, Kurt Heiritz (pseudo), Esteban Kuber, Kaoet, Petr Portnov | PROgrm_JARvis, Kornel, NyxAlexandra and Max Heller- addedI-lang-radarItems that are on lang's radar and will need eventual work or consideration.Items that are on lang's radar and will need eventual work or consideration.and removedI-lang-nominatedNominated for discussion during a lang team meeting.Nominated for discussion during a lang team meeting.P-lang-drag-1Lang team prioritization drag level 1. https://rust-lang.zulipchat.com/#narrow/channel/410516-t-langLang team prioritization drag level 1. https://rust-lang.zulipchat.com/#narrow/channel/410516-t-lang
on Sep 17, 2025 - added 2 commits that reference this issue
on Sep 24, 2025 - added a commit that references this issue
on Mar 15, 2026 See #88744 (comment)
I still feel like we should just support the
[T; 0]impl and can actually do so. We can either do so by relying on specialization, similar to #74254, or by adding a new lang item to std as was done in #84838.We could also use const generic hacks (GCE or GCI + OGCA)
- addedT-libsRelevant to the library team, which will review and decide on the PR/issue.Relevant to the library team, which will review and decide on the PR/issue.and removedT-libs-api[DEPRECATED; DO NOT USE][DEPRECATED; DO NOT USE]
on Aug 12, 2026
View all comments
Currently, we generate array impls for every size up to 32 manually using macros, but with const generics at a suitable level of implementation, we can switch to properly parameterising over all lengths.
Defaultimpl with const generic impl (more difficult due to Switch libcore array implementations to const generics. #60466 (comment)).rust/src/libcore/array.rs
Lines 221 to 227 in 7840a0b
rust/src/liballoc/vec.rs
Lines 2199 to 2204 in bfdfa85