pub fn read_complex_slice<T: BeveTypedSlice>(
input: &[u8],
) -> Result<Vec<Complex<T>>>Expand description
Decode a BEVE complex array (the bytes produced by write_complex_slice /
to_vec_complex_slice) into a Vec<Complex<T>> in a single bounds-checked
bulk read — the read counterpart of the bulk writer.
Like the writer, this is opt-in and requires the caller to name the element
type T: serde’s Deserialize for Vec<Complex<T>> pulls elements one at a
time through nested visitors and never sees the contiguous little-endian
block, so the generic from_slice path cannot take it automatically. On
little-endian targets the whole payload is moved into the result with one
copy_nonoverlapping after a single bounds check (a single bulk copy, not
zero-copy: the input bytes may be unaligned for Complex<T>); on big-endian
targets it copies and then byte-reverses each scalar in place.
Errors if input is not a complex array extension, if the on-wire
class/byte-code do not match T, or if the payload is truncated. Any bytes
after the array are ignored (matching crate::from_slice); the function
returns only the decoded Vec, so it does not report how many bytes were
consumed.
The class check is deliberately strict, and stricter than the serde paths: a
complex i16 array read into a Vec<Complex<f32>> field converts there
(both with and without a #[serde(with = "beve::complex_array::f32")]
annotation), where here it is a Error::Mismatch. Naming T is this
function’s entire interface — there is no schema and no Deserialize impl
behind it to state one — so the type you name is taken as the assertion, and
converting instead would leave nothing that could ever fail. Decode through
serde if you want the conversion.
§Example
use beve::Complex;
let data = [Complex { re: 1.0f64, im: -2.0 }, Complex { re: 3.5, im: 4.25 }];
let bytes = beve::to_vec_complex_slice(&data);
let back = beve::read_complex_slice::<f64>(&bytes).unwrap();
assert_eq!(back, data);