Skip to content

Use const generics for array Default impl #61415

Description

@varkor

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.

  • Replace most manual impls with const generic impls (PR: Use const generics for array impls [part 1] #62435)
  • Replace Default impl with const generic impl (more difficult due to Switch libcore array implementations to const generics. #60466 (comment)).
  • Reimplement impls removed due to bloat using const generic impls (see

    rust/src/libcore/array.rs

    Lines 221 to 227 in 7840a0b

    // NOTE: some less important impls are omitted to reduce code bloat
    __impl_slice_eq1! { [A; $N], [B; $N] }
    __impl_slice_eq2! { [A; $N], [B] }
    __impl_slice_eq2! { [A; $N], &'b [B] }
    __impl_slice_eq2! { [A; $N], &'b mut [B] }
    // __impl_slice_eq2! { [A; $N], &'b [B; $N] }
    // __impl_slice_eq2! { [A; $N], &'b mut [B; $N] }
    and

    rust/src/liballoc/vec.rs

    Lines 2199 to 2204 in bfdfa85

    // NOTE: some less important impls are omitted to reduce code bloat
    // FIXME(Centril): Reconsider this?
    //__impl_slice_eq1! { [const N: usize] Vec<A>, &mut [B; N], [B; N]: LengthAtMost32 }
    //__impl_slice_eq1! { [const N: usize] Cow<'a, [A]>, [B; N], [B; N]: LengthAtMost32 }
    //__impl_slice_eq1! { [const N: usize] Cow<'a, [A]>, &[B; N], [B; N]: LengthAtMost32 }
    //__impl_slice_eq1! { [const N: usize] Cow<'a, [A]>, &mut [B; N], [B; N]: LengthAtMost32 }
    )

Activity

  1. added
    T-langRelevant to the language team
    T-libs-api[DEPRECATED; DO NOT USE]
    T-compilerRelevant to the compiler team, which will review and decide on the PR/issue.
    A-const-genericsArea: const generics (parameters and arguments)
    on May 31, 2019
  2. added
    C-tracking-issueCategory: An issue tracking the progress of sth. like the implementation of an RFC
    on May 31, 2019
  3. Centril commented on May 31, 2019

    @Centril
    Contributor

    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.

  4. petrochenkov commented on Jun 1, 2019

    @petrochenkov
    Contributor

    We 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 where clause with the marker trait).

    This way const generics would be an implementation detail, so their stabilization wouldn't be required.

  5. varkor commented on Jun 3, 2019

    @varkor
    ContributorAuthor

    The results from the crater run and perf run for using const generics for array impls are in (#60466).

    I think there's good reason to go with @petrochenkov's suggestion (#61415 (comment)) and potentially consider lifting the restriction for array sizes.

  6. pnkfelix commented on Jun 6, 2019

    @pnkfelix
    Contributor

    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?

  7. alexcrichton commented on Jun 13, 2019

    @alexcrichton
    Member

    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)

  8. nikomatsakis commented on Jun 20, 2019

    @nikomatsakis
    Contributor

    The @rust-lang/lang team discussed this and we agree with the libs team. =)

  9. scottmcm commented on Jul 6, 2019

    @scottmcm
    Member

    No-expanded-surface area (#61415 (comment)) PR up at #62435

  10. 53 remaining items

  11. traviscross commented on Sep 17, 2025

    @traviscross
  12. rust-rfcbot commented on Sep 17, 2025

    @rust-rfcbot
  13. removed
    proposed-final-comment-periodProposed 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.
    on Sep 17, 2025
  14. traviscross commented on Sep 17, 2025

    @traviscross
    Contributor

    We talked about this question -- using const generics for the Default impl on arrays and supporting the unconditional [T; 0]: Default as 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 some x: T works for N < 2 even when T: ?Copy, how constants are instantiated and dropped N times, etc. The magic needed for Default doesn'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.

  15. added
    I-lang-radarItems that are on lang's radar and will need eventual work or consideration.
    and removed
    I-lang-nominatedNominated 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-lang
    on Sep 17, 2025
  16. scimind2460 commented on Oct 29, 2025

    @scimind2460
    Contributor
  17. added a commit that references this issue on Mar 15, 2026
    5af2045
  18. scimind2460 commented on Mar 16, 2026

    @scimind2460
    Contributor

    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)

  19. added
    T-libsRelevant to the library team, which will review and decide on the PR/issue.
    and removed
    T-libs-api[DEPRECATED; DO NOT USE]
    on Aug 12, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    A-arrayArea: `[T; N]`A-const-genericsArea: const generics (parameters and arguments)A-sliceArea: `[T]`I-lang-radarItems that are on lang's radar and will need eventual work or consideration.I-libs-radarLibs issues that are tracked on the team's radar.T-compilerRelevant to the compiler team, which will review and decide on the PR/issue.T-langRelevant to the language teamT-libsRelevant to the library team, which will review and decide on the PR/issue.

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions