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).

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.