`impl Default` for generically sized arrays? (`[T; N]`)

CAD97 · 2025-08-13T00:02:43.339Z

SkiFire13:

lattice rule

Specifically, this should theoretically be a sound usage of specialization:

impl<T: Default, const N: usize> Default for [T; N] {
    default fn default() -> [T; N] {
        array::from_fn(|_| T::default())
    }
}

impl<T> Default for [T; 0] {
    default fn default() -> [T; 0] {
        []
    }
}

impl<T: Default> Default for [T; 0] {
    override fn default() -> [T; 0] {
        []
    }
}

but the difficulty comes from teaching the compiler to prove that this is sound. The impl selection for [T; 0] is potentially dependent on lifetimes (e.g. if you have impl Default for Type<'static>), so this is only sound specifically because the two impls are equivalent.

Perhaps this could be allowed with something along the lines of

impl<T: Default, const N: usize> Default for [T; N] {
    default fn default() -> [T; N] {
        array::from_fn(|_| T::default())
    }
}

#[bikeshed_specialization_choose_this_one_for_overlaps]
impl<T> Default for [T; 0] {
    final fn default() -> [T; 0] {
        []
    }
}

where we allow the second impl to partially specialize the first without the use of a separate lattice impl because we have explicitly noted which impl should be used in the overlap (and the chosen impl is "always applicable" (doesn't introduce non-const bounds)).

SciMind2460 · 2025-08-29T09:21:23.049Z

I think this is an issue about whether we care enough about impl<T> Default for [T; 0] breaking versus the possibilities available with a const generics impl. In my opinion, the latter is better, and it is a time to break from the past, as even without the former, we can still use []. I may be wrong though...

Vorpal · 2025-08-29T18:13:32.445Z

Rust does not break backward compatibility. Except for soundness and security issues, and even there only when absolutely required.

However, sometimes theoretical backwards compatibility breaks are accepted if it can be shown via a crater run that no one actually depends a specific behaviour.

SciMind2460 · 2025-08-30T10:57:53.560Z

Maybe we can do a crater run and see how much it impacts?

the8472 · 2025-08-30T12:59:27.769Z

We can do without lattice specialization here. We can use marker traits to define the public signature and then exploit that the non-Default case is a noop. But this still needs full specialization since it has to specialize on a public trait, so we still can't have this in core.

#![feature(marker_trait_attr)]
#![feature(specialization)]

#[marker]
trait EmptyOrDefault {}

impl<T: Default, const N: usize> EmptyOrDefault for [T; N] {}
impl<T> EmptyOrDefault for [T; 0] {}


impl<T, const N: usize> local::Default for [T; N] where Self: EmptyOrDefault {
    fn default() -> Self {
        <Self as ArrDefaultSpec<T, N>>::default()
    }
}

trait ArrDefaultSpec<T, const N: usize> {
    fn default() -> [T; N];
}

impl<T, const N: usize> ArrDefaultSpec<T, N> for [T; N] {
    default fn default() -> [T; N] {
        if N == 0 {
            return unsafe { core::mem::zeroed() }
        }
    
        unreachable!("always specialized")
    }
}

impl<T, const N: usize> ArrDefaultSpec<T, N> for [T; N] where T: Default {
    fn default() -> [T; N] {
        core::array::from_fn(|_| Default::default())
    }
}

// just to avoid coherence
mod local {
    pub trait Default {
        fn default() -> Self;
    }
}

quinedot · 2025-08-30T17:17:04.484Z

SciMind2460:

Maybe we can do a crater run and see how much it impacts?

github.com/rust-lang/rust

Experiment: Add `where T: Default` to `Default for [T; 0]` impl.

master ← m-ou-se:default-array-zero

opened 03:20PM - 15 Aug 25 UTC

m-ou-se

+1 -8

*Not to be merged; just an experiment.* I'm curious how many crates rely on t…he `Default for [T; 0]` implementation not having a `T: Default` bound. Let's do a crater check run to find out. :)

ais523 · 2025-08-30T18:11:53.044Z

Looks like there are three actual uses of this in the latest versions of code visible to crater:

in a Github repository
in another Github repository, and
in code generated by the tuplez-macros crate (crater reports the error at uses of the macro rather than the definition; the offending line is here).

It's heartening that in all of these cases, the break was someone directly writing Default::default() when they could have written [] instead – there were no cases where generic code that needed a Default value was picking up the implementation on [T; 0].

I also checked cases where current code is linking against old versions of crates that use the impl (but where the dependency has a more recent version that doesn't use the impl). Most of them were the same situation (someone writing Default::default() where they could have written []), but an old version of foundations attempts to implement a trait that requires Default on [T; 0]. There's also an old version of spacetimedb-sats that uses a call to Default with an annotaiton (in the style of <[T; 0]>::default()), which can't trivially be replaced with [] because there isn't an easy way to specify the type of an empty array.

Also notable is that an old version of bevy-ecs writes Default::default() rather than [] – the code in question is not present in more recent versions, but bevy is used widely enough that many projects have old versions of bevy-ecs in their lock files.

I'm not sure whether this is enough breakage to veto the change, especially given that the edition mechanism probably doesn't help. I guess it might be possible to make calls to Default::default() be interpreted as though they said [] in old editions, in cases where the type is known from the callsite to be an empty array type; this would fix almost all the practical problems from the change (although it would still technically be breaking), but that would be a very weird ad-hoc fix (sort of like specialisation but confined only to callsites where an explicit call were written).

SciMind2460 · 2025-08-31T03:36:00.738Z

Hmm... this seems interesting. Maybe we can do a

impl<T>  [T; 0] {
    fn default() {
        []
    }
}

as a part-way stopgap measure?

ais523 · 2025-08-31T03:49:42.692Z

The problem there is that most of the existing uses wrote it as Default::default rather than <[T; 0]>::default, and writing the name of the trait means that an inherent impl won't be used.

SciMind2460 · 2025-08-31T05:39:52.814Z

An if-else impl allowed on traits like this:

impl<T, const N: usize> Default for [T; N] where const {
    if N != 0 {
        T: Default
    }
} {
    fn default() {
        if N != 0 {
            [T::default(); N]
        } else {
            []
        }
    }
}

would be really helpful. I got the idea of a const function that could change type signature dependent on const params. So, essentially we could generate many functions dependent on type signature and we could specify how many of these functions we could generate.

This idea is still very nebulous and I need some help fleshing it out.

SkiFire13 · 2025-08-31T06:19:45.253Z

The hard part of such proposals is how to do trait resolution with them in generic contexts. For example how would the compiler prove that Default is implemented for [T; N] with T and N generic? Your const block needs knowledge about N to be executed, but N is not known, so this would effectively be stuck. You could argue that it should try all possibilities, and it might work in simple cases, but in general this is effectively equivalent to solving the halting problem.

CAD97 · 2025-09-03T18:53:38.783Z

the8472:

We can do without lattice specialization here.

Clever. I'm not fully aware of the specialization-as-is details, to be fair, even though I think I have a good grasp on specialization-in-the-ideal.

Though to be clear, I brought up lattice specialization for two purposes:

it had already been mentioned in passing, and I wanted to clarify what that meant for passers by, and
to share the observation that the specialization is sound, despite the specialization on an existing public trait[^1], due to the overlap being source-equivalent to an always-applicable implementation.

[^1] i.e. one that can be implemented potentially dependent on lifetimes

DanielFath · 2025-09-03T22:30:23.727Z

SkiFire13:

[snip] I believe specialization with the lattice rule should allow writing this kind specialization.

The lattice rule? What is that?

zirconium-n · 2025-09-04T02:29:23.415Z

When two specialization overlaps, you must write a new specialization for the intersection of them. In this case, [T; 0] and [T; N] where T: Default overlaps, so you have to write specialization for [T; 0] where T: Default.

This resolve the question of what happens when a type can fit into multiple specializations: there's always a specialization that fits the best.

CAD97 · 2025-10-05T20:57:27.545Z

T-lang was okay with pin! using nightly/internal features specifically because they were okay committing to something like what pin! does^[1] being available in perpetuity to accomplish pin!.

I wonder if they'd be willing to do similar for impl Default for [impl Sized; 0] overlapping impl Default for [impl Default; _]. It's a lot more impactful to what we commit to being possible at some level, but it's also the absolute simplest form of "obviously correct" overlap possible — all of the overlapping cases provide the exact same implementation (after MIR inlining).

Specifically, field access to a private field and/or the ability to super let an extended temporary in the macro calling scope. ↩︎

kpreid · 2025-10-05T23:31:43.210Z

CAD97:

I wonder if they'd be willing to do similar for impl Default for [impl Sized; 0] overlapping impl Default for [impl Default; _].

Already said yes: Use const generics for array `Default` impl · Issue #61415 · rust-lang/rust · GitHub

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.

… 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 …

SciMind2460 · 2025-10-09T04:50:31.296Z

I've created a new topic that would perhaps make groundwork on creating a comprehensive framework for lattice specialisation on const generics.

I believe that this would be sound for the reasons mentioned in the topic, and would request comments on the idea.

My idea is that specific instances of a type (for example, 0: u32) will be given a higher priority than generic instances const T: u32. Perhaps later we could incorporate pattern types as a middle ground.

bascule · 2025-10-11T14:49:17.430Z

Sidebar: this whole debacle makes me wonder if there should be some defined process by which Rust's current stability guidelines can be violated, either in the form of actually releasing a Rust 2.0 with a very limited subset of breaking changes, or a process for breaking changes to Rust 1.0.

In this case, the actual practical implications of the breaking change are minuscule, and the benefits are IMO huge. I can't emphasize enough how many times I've encountered it in the years since const generics have been released and had to come up with convoluted ways to work around with, including but not limited to writing my own array newtype crate.

josh · 2025-10-11T16:23:36.168Z

There is such a process (albeit not well documented): a crater run to see what breaks, assessing the impact, coordination with the crates affected, FCWs if there are many of them, and a transition period.

SciMind2460 · 2025-10-31T09:48:49.749Z

@WaffleLapkin and I have initiated the coordination with the crates affected. 4 out of the 8 unarchived root failures responded, 3 positively and 1 negatively (this was due to not signing the CLI).