Repository navigation
Fixed-length arrays implement no traits #7622
Description
Activity
Nominating for feature-complete.
Just a bug, de-nominating
Reacted by chpio and Oscar LindeReacted by chpio- changed the title
[-]Fixed-length vectors implement no traits[/-][+]Fixed-length arrays implement no traits[/+]on Apr 13, 2014 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.
@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 iffoois a method on&[T]; however, this is not usable in generlc code, e.g. aVec<[T, .. n]>can't be treated as aVec<&[T]>because the memory representations differ. Furthermore, the dynamicVec<T>incurs an allocation and a pointer indirection (along with 2 words of metadata) while[T, .. n]is literally justninstances ofTstored 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).
Reacted by lolbinarycatIt 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
Cloneimplementation for[T, ..n]whereT: Clone.This seems to be fixed: http://is.gd/B7JN4n (rust playpen).
It looks like it's only fixed for arrays up to size 32: http://is.gd/LHWkJK
It's still a problem that arrays only implement
ClonewhenT: Copy.Reacted by yongqliThis 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.
Reacted by Peter Hall, chpio, Ronny Herzog, Ingvar Stepanyan, Ivan Smirnov and Jeff BurdgesClosing; 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.)
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):