#slice #flatten #utils #nest #no-std

no-std slice-of-array

Extension traits for casting between slices and slices of arrays. (&[T] <-> &[[T; n]])

7 releases

0.3.2 Mar 23, 2022
0.3.1 Apr 11, 2021
0.2.1 Nov 12, 2018
0.2.0 Apr 27, 2018
0.1.1 Oct 13, 2017

#650 in Data structures

Download history 346/week @ 2023-12-18 245/week @ 2023-12-25 235/week @ 2024-01-01 497/week @ 2024-01-08 379/week @ 2024-01-15 296/week @ 2024-01-22 151/week @ 2024-01-29 465/week @ 2024-02-05 452/week @ 2024-02-12 351/week @ 2024-02-19 377/week @ 2024-02-26 455/week @ 2024-03-04 571/week @ 2024-03-11 417/week @ 2024-03-18 370/week @ 2024-03-25 530/week @ 2024-04-01

1,937 downloads per month
Used in 26 crates (11 directly)


242 lines

Crates.io Docs.rs


Extension traits on [T] for converting to and from [[T; n]].

slice-of-array = "0.3.2"
extern crate slice_of_array;
use ::slice_of_array::prelude::*;

let vec = vec![[1, 0], [0, 1]];
let _: &[i32] = vec.flat();
let _: &[[[i32; 2]; 1]] = vec.nest();
let _: &[[i32; 2]; 2] = vec.as_array();

Use types like &[[f64; 3]] in your public interfaces without fear!

You'll be able to flatten that stuff just fine when delegating work to (insert your favorite linear algebra library here)!

Not to mention everybody using your library will have no problem creating the necessary slice types to use your interface.

...uh, that is, assuming that they also have found this or a similar crate. And that they aren't internally using something like (f64, f64, f64) or some #[repr(rust)] struct. Or a structure of arrays.

Can't win 'em all.


Oh god not another slice-to-array library

Hey hey hey, hold on here! This is not a slice-to-array library. It is a slice of array library! Everybody and their mother has published their own crate for converting between &[T] and &[T; n] on crates.io, but only slice-of-array™ lets you convert between &[T] and &[[T; n]].

That said... uh, yes, one of its features is indeed casting slices to arrays. I'm sorry.

Panics by default?

Panics by default.

It's main purpose is for bridging between APIs that work on flattened vectors and APIs that work on slices of arrays. In these places where it is intended to be used, you already know that your data is of the appropriate shape, and Option would get in the way.

I want to make a Vec<_> instead of &[_]

.flat().to_vec() or .nest().to_vec()

No no no, I want to make a Vec<_> with zero cost

Yikes! You're messing with metadata that's going to be handed to the allocator when your vec falls out of scope, and I don't think the allocator likes surprises. I don't want that on my conscience!

If you're convinced that this problem has a solution, then please submit a PR.


No runtime deps