Fixed-length arrays implement no traits

[huonw]

Currently fixed-length arrays (i.e. [f64, .. 3]) implement no traits, because each size needs to be implemented separately. It'd be nice to be able to parameterise the length.

One consequence is that #[deriving] doesn't work with them (and gives strange error messages):

#[deriving(Eq)]
struct SuDoku {
    map: [[uint, .. 9], .. 9]
}

$ rustc --lib sudoku.rs
sudoku.rs:1:11: 1:14 error: mismatched types: expected `&&[[uint, .. 9]]` but found `&[[uint, .. 9], .. 9]` ([] storage differs: expected & but found 9)
sudoku.rs:1 #[deriving(Eq)]
                       ^~~
sudoku.rs:1:11: 1:14 error: failed to find an implementation of trait core::cmp::Eq for [uint, .. 9]
sudoku.rs:1 #[deriving(Eq)]
                       ^~~

[huonw]

Nominating for feature-complete.

[catamorphism]

Just a bug, de-nominating

[yokto]

The way Haskell has solved this (at least in the case of tuples) is to simply add instances for the first 10 cases. Since, in Haskell, instances need not be in the same module as the class or datatype declaration, a programmer can always add instances for higher numbers if he needs them. Also, for the implementation of higher numbers the programmer could probably just use the implementation of non-fixed sized arrays.

[huonw]

@yokto we do the same for tuples (mainly via macro generated trait implementions), however the main use case for fixed sized arrays is "large" homogeneous sequences, the ratio between small and large fixed sized vectors will be smaller than small/large tuples so the small implementations won't be as helpful (unfortunately).

Also, for the implementation of higher numbers the programmer could probably just use the implementation of non-fixed sized arrays.

Currently [T, .. n] "inherits" functions from &[T] (and &mut [T]), since it coerces automatically, e.g. fixed_array.foo() will work if foo is a method on &[T]; however, this is not usable in generlc code, e.g. a Vec<[T, .. n]> can't be treated as a Vec<&[T]> because the memory representations differ. Furthermore, the dynamic Vec<T> incurs an allocation and a pointer indirection (along with 2 words of metadata) while [T, .. n] is literally just n instances of T stored inline, with no overhead.

This is important for low-level programming (like writing an operating system) where allocations are impossible, and also for performance, since stack allocation is nicer for CPU caches (as well as just avoiding the cost of doing the allocation).

[ghost]

Fixed in #18486. Closing.

[thestinger]

It doesn't seem like #18486 is relevant to this issue. It's still not possible to implement traits for fixed-size arrays of any size. An especially awful case is the lack of a Clone implementation for [T, ..n] where T: Clone.

[gifnksm]

This seems to be fixed: http://is.gd/B7JN4n (rust playpen).

[martinraison]

It looks like it's only fixed for arrays up to size 32: http://is.gd/LHWkJK

[apasel422]

It's still a problem that arrays only implement Clone when T: Copy.

[amluto]

This is particularly problematic with rust-bindgen. rust-bindgen generates things like this:

pub struct Union_Unnamed11 {
    pub _bindgen_data_: [u8; 283usize],
}

for unions, and the resulting struct cannot be Copy at all and cannot derive Clone.

It looks like this could be very cleanly fixed if rust-lang/rfcs#1038 (types parametrized over numbers) happened.

[aturon]

Closing; this issue is really subsumed by the desire for const generics, and we've done all we can until those land. (And when they do come, we'll generalize the current trait impls accordingly.)