Zero-length arrays are non-Copy.

[JohnScience]

According to the documentation of core::marker::Copy,

Generally speaking, if your type can implement Copy, it should. Keep in mind, though, that implementing Copy is part of the public API of your type. If the type might become non-Copy in the future, it could be prudent to omit the Copy implementation now, to avoid a breaking API change.

Zero-sized types in general are a bit tricky in that regard because they (just like core::marker::PhantomData) can be used to represent ownership over values of types that non-trivially implement core::ops::Drop.

However, zero-length arrays perhaps should implement Copy because they can be bit-wise copied (assuming 0-bit/0-byte copy is permitted). It would allow implementing Copy on overaligned types like the one below:

Is there anything that stops implementing Copy on zero-length arrays aside from marker trait attribute dependency?

P.S. I would love to have a generic type where the first generic parameter would be the type of the stored value and the second parameter would be a generic constant of type usize whose value would be used as a constraint for alignment, yet it is a story for discussion on Rust internals/another issue/RFC.

References

• "What is overalignment of execution regions and input sections?", Stack Overflow

[oli-obk]

cc @rust-lang/project-const-generics

[lcnr]

Is there anything that stops implementing Copy on zero-length arrays aside from marker trait attribute dependency?

pretty much, yeah. Though I am not sure we want it even once marker trait attributes, as it will be inconsistent with other traits which also rely on lattice specialization, e.g. Clone and so on

[JohnScience]

@lcnr Can you please explain the inconsistency?

[lcnr]

We won't be able to implement Clone for zero-length arrays without having lattice specialization or by adding some hacks to the compiler.

e.g. see Default which had the special-case for 0 length arrays and now can't be implemented using const generics https://doc.rust-lang.org/nightly/std/default/trait.Default.html#impl-Default-71.

So if we add impl<T> Copy for [T; 0] once marker traits are stable, we still won't have these impls for Clone and so on, even though they are just as sensible.

Additionally, Clone is a supertrait of Copy, so you wouldn't be able to add a Copy impl without first implementing Clone.

[workingjubilee]

Using 0-length arrays to align things is a hack and should be replaced by an actually fluent interface to adjust layout computations based on various parameters.

[JohnScience]

I suggest the following labels for the issue:

• A-array
• A-layout
• F-marker_trait_attr
• F-specialization

Since I can't account for everything and write a reasonable RFC, I think that this issue can remain open until someone finds it useful enough to implement.

[JohnScience]

I want to do something terribly unsafe. I would like to have a struct implement Copy even though the field storing a zero-sized array doesn't. Any ideas which terrible hacks would help me achieve that?

Note: core::mem::ManuallyDrop<T> implements Copy only if T: Copy

[zirconium-n]

Not really solving [T; 0] is non-Copy, but for force alignment, it seems generic_const_exprs would suffice?

#![feature(generic_const_exprs)]
use std::mem::align_of;

fn main() {
    println!("{}", align_of::<K>());  // 8
    println!("{}", align_of::<X<K>>());  // 8
}

struct K(u64);

struct X<A: Sized>
where
    (): AlignT<{ align_of::<A>() }>,
{
    k: [<() as AlignT<{ align_of::<A>() }>>::T; 0],
    x: u8,
}

trait AlignT<const N: usize> {
    type T: Copy;
}

impl AlignT<8> for () {
    type T = u64;
}

impl Copy for X<K> {}
impl Clone for X<K> {
    fn clone(&self) -> Self {
        *self
    }
}

[lukas-code]

This would be another application of an unsafe impl Copy, as proposed in #62835 and #25053.