Instantiating SIMD types as tuple literals becomes absolutely hand-cramping when those structs become wider than 2~8 elements, and even 8 is getting a bit tiresome. CTFE is now powerful enough to significantly sugar some fairly nuanced array creation, e.g.:
const ARRAY: [i8; 32] = {
let mut arr = [-128; 32];
arr[27] = -62
arr[30] = -31;
arr[31] = -15;
arr
};By providing, at the very least, conversions from the obvious arrays into SIMD types, we can make a lot of things easier on ourselves, so that this can just be used with some kind of method like i8x32::from_array(ARRAY).
Because arrays are a much more natural fit, I would honestly like to explore "what compiler changes would be required to let #[repr(simd)] accept arrays straight-out?" but that may quickly become too complicated, so for now it is just a (very) nice-to-have and std::simd conversions can still exist. On the other hand, it might be pretty easy, and that might simplify the overall API for us immensely, so I should at least check.
Instantiating SIMD types as tuple literals becomes absolutely hand-cramping when those structs become wider than 2~8 elements, and even 8 is getting a bit tiresome. CTFE is now powerful enough to significantly sugar some fairly nuanced array creation, e.g.:
By providing, at the very least, conversions from the obvious arrays into SIMD types, we can make a lot of things easier on ourselves, so that this can just be used with some kind of method likei8x32::from_array(ARRAY).Because arrays are a much more natural fit, I would honestly like to explore "what compiler changes would be required to let
#[repr(simd)]accept arrays straight-out?" but that may quickly become too complicated, so for now it is just a (very) nice-to-have andstd::simdconversions can still exist. On the other hand, it might be pretty easy, and that might simplify the overall API for us immensely, so I should at least check.