Add SimdArray trait and safe gather/scatter API

[workingjubilee]

This PR has four parts, without which it doesn't make a lot of sense:

0. The introduction of the SimdArray trait for abstraction over vectors.
1. The implementation of private vector-of-pointers types.
2. Using these to allow constructing vectors with SimdArray::gather_{or, or_default, select}.
3. Using these to allow writing vectors using SimdArray::scatter{,_select}.

[programmerjake]

Naming question: Do we want the gather/gather_or methods to take a mask? or will the masked variant be named gather_masked?

Maybe like:

// excuse my syntax
impl ... for SimdUsize<...> {
    fn gather_or<T>(self, slice: &[T], mask: ..., fallback: Simd<[T; LANES]>) -> Simd<[T; LANES]>;
    fn gather_or_default<T>(self, slice: &[T], mask: ...) -> ...;
}

[workingjubilee]

discussed in meeting, consensus was largely...

On the trait

0. SimdArray is an okay name, but we may want to rename SimdArray to Vector in the very near future (like, right before debut to nightly), just to find out the Rust community's opinion on it. :^)
1. Having methods on a trait is fine, but we probably want to max out on a very small number of "big" crate-defined expected-to-be-imported traits for users though. Ideally just 2: {Vector,SimdArray} and perhaps {Mask,SimdMask}?
2. We'd like inherent implemented traits in a bright and shiny future but it's fine if they're not, as long as we're very disciplined about limiting required traits to use our API, see previous remark.
3. There was some concurrence re: signal to noise ratio in an API based on the number of methods and how "partitioned" they were (or not, as the case may be) in the documentation.
4. Maybe someday we'll have SimdInt or SimdFloat trats and the like, but definitely not in this crate for now.

On the methods

0. No "default, unmasked" fn gather, call it fn gather_or_default instead.
1. And it's fine if fn scatter has no exact parallel.
2. fn gather_select and fn scatter_select will be the masked versions.

[calebzulawski]

Looking this over again, shouldn't the lane count be an associated const?

pub trait SimdArray {
    const LANES: usize;
}

It's impossible to implement SimdArray with different lengths for a single type.

[workingjubilee]

Hm... is that a bug?

[workingjubilee]

I am OK with using an assoc const fwiw, I just genuinely don't know which one would actually be best here. My operating assumption is that they have different implications re: const unification and type inference and I don't know what actually will offer the more ergonomic API until we rework more stuff.

[calebzulawski]

The associated const would let you do something like <T as SimdArray>::LANES which I could see being useful. No easy way to extract the lane count otherwise, I think.

[thomcc]

Also it follows the best practice of "if you want to allow this type to implement the trait multiple times, use a type const parameter, otherwise use an associated type const".

EDIT: lol i said it backwards first.

[workingjubilee]

I can add the assoc const on its own but removing the const from the trait definition induces a cycle in evaluating the well-formedness of the const generic, so I think it can't be done.

[calebzulawski]

I'll check it out in a bit, just to see if I can convince it. I don't see why it shouldn't work.

[workingjubilee]

cc @rust-lang/project-const-generics since we seem to be running into an amusing niche case in our expectations of how const things work and interact with Rust programming idioms, vs. how they do in practice.

for note: my attempt was to bound everything currently described by LANES on Self::LANES and instead write stuff like

impl SimdArray for Simd{Ty}<LANES> {
    const LANES: usize = LANES;
}

and I experimented with a few different configurations of where-bounds and the like, but I kept hitting cycles or outright failures to type check.

[workingjubilee]

After finding that the problem is probably in the bounds not being moved mostly into the implementations of the traits, we will probably catch up to refactoring this in after a bit more tinkering around.