Use generic trait parameters to minimize associated types

[calebzulawski]

This improves type inference by removing most associated types. For example, the following function doesn't actually work:

fn foo<T: SimdElement>(x: Simd<T, 4>) -> Mask<T::Mask, 4>
where
    Simd<T, 4>: SimdFloat,
{
    x.is_sign_negative()
}

You actually need the constraint Simd<T, 4>: SimdFloat<Mask = Mask<T::Mask, 4>>.

With this PR, the function should look a little more like:

fn foo<T: SimdElement>(x: Simd<T, 4>) -> Mask<T::Mask, 4>
where
    Simd<T, 4>: SimdFloat<T, 4>,
{
    x.is_sign_negative()
}

There are still a few instances that need associated types, but we can explore those individually to see if there's a better API.

Also, note that we now end up with a lot of instances of Mask<<T as SimdElement>::Mask, N>. We can either remove the SimdElement::Mask associated type with #483 or we can provide an alias to avoid writing that out.

[programmerjake]

imo N should be an associated #[type_const] but last I knew that's not done being implemented yet.

something like:

pub trait SimdLen {
    #[type_const]
    const LEN: usize;
}

impl<T: SimdElement, const N: usize> SimdLen for Simd<T, N> {
    #[type_const]
    const LEN: usize = N;
}

impl<T: MaskElement, const N: usize> SimdLen for Mask<T, N> {
    #[type_const]
    const LEN: usize = N;
}

pub trait SimdBase: SimdLen {
    type Element: SimdElement;
}

impl<T: SimdElement, const N: usize> SimdBase for Simd<T, N> {
    type Element = T;
}

pub trait SimdPartialEq: SimdBase {
    fn simd_eq(self, other: Self) -> Mask<<Self::Element as SimdElement>::Mask, { Self::LEN }>;
    ...
}

[programmerjake]

that would allow your example function's bounds to just be:

fn foo<T: SimdElement>(x: Simd<T, 4>) -> Mask<T::Mask, 4>
where
    // output types are completely deduced from the blanket
    // SimdBase and SimdLen impls so no additional bounds are needed
    Simd<T, 4>: SimdFloat,
{
    x.is_sign_negative()
}

[programmerjake]

sadly, it seems that hits the bug where specifying bounds hides information that could be deduced so the bound ends up having to be:
Simd<T, 4>: SimdFloat<Element = T, LEN = 4>

https://play.rust-lang.org/?version=nightly&mode=debug&edition=2024&gist=c84993a34513e1f45a01b986533be269

[programmerjake]

I got it to work with just Simd<T, 4>: SimdFloat by removing SimdFloat: SimdBase and instead having where Self: SimdBase on all items in the trait.

https://play.rust-lang.org/?version=nightly&mode=debug&edition=2024&gist=c13634f70837e4b761b6a19592d069d9

[programmerjake]

further reduced feature gates: https://play.rust-lang.org/?version=nightly&mode=debug&edition=2024&gist=b57a420a75142e3eda48993dc2f981f1

[Keith-Cancel]

the Inc/Dec parts seems very much like typenum which I think is something Rust should avoid in stable interfaces in the standard library since I think Rust should have generic const expressions for that kind of thing instead of using types to do arithmetic. Also, the finite list of impls for specific integers is what we just removed in #485.

@programmerjake Those where more there at least for what I am using that for to generically do truncate or extend with operations while allowing me to specify constraints on the N, since const equality is also not stable either, not sure such operation would be needed for SIMD though. I more of just posted what I had to show that types can be used to replace a [type_const] associated const. A first class language construct is definitely nicer than a bunch type machinery boilerplate definitely agree!

[programmerjake]

if you're trying to be generic over multiple lengths, of course you need a const N: usize generic. if you instead have one or more known lengths that you're not generic over, I intended that you shouldn't need bounds mentioning generic lengths.

imo Simd<T, N> ideally shouldn't need more or less trait bounds for lengths than [T; N], so if you're trying to be generic over length having fn f<const N: usize>(v: Simd<f32, N>) seems good to me. imo you shouldn't need to mention known or generic lengths anywhere other than the N in Simd<T, N> (or Mask), so I don't like having to have Simd<T, N>: SomeTrait<N> + OtherTrait<N> where you have to repeat the N in all the trait bounds.

[Keith-Cancel]

if you're trying to be generic over multiple lengths, of course you need a const N: usize generic. if you instead have one or more known lengths that you're not generic over, I intended that you shouldn't need bounds mentioning generic lengths.

imo Simd<T, N> ideally shouldn't need more or less trait bounds for lengths than [T; N], so if you're trying to be generic over length having fn f<const N: usize>(v: Simd<f32, N>) seems good to me. imo you shouldn't need to mention known or generic lengths anywhere other than the N in Simd<T, N> (or Mask), so I don't like having to have Simd<T, N>: SomeTrait<N> + OtherTrait<N> where you have to repeat the N in all the trait bounds.

Yea but an associated #[type_const] would allow such a function to just be fn f<T: Simd<f32>>(v: T).

--Edit
@programmerjake Also if you need constraint the length you could do something like:
fn f<T: Simd<f32, N = 4>>(v: T) ect..

That number trait I have allows something similar, I guess the main thing I don't like about it is that it makes my arrays opaque to just what trait constraint I put on it. Although the commented out ArrayLike trait allowed me to get around most the issues of that.

[programmerjake]

Yea but an associated #[type_const] would allow such a function to just be fn f<T: Simd<f32>>(v: T).

Yes (if you used an actual trait rather than the Simd type). That said, I think using the Simd<f32, N> type is waay better, similar to how it's standard practice to write fn f<const N: usize>(v: [f32; N]) instead of fn f<T: ArrayOf<f32>>(v: T).

-Also if you need constraint the length you could do something like: fn f<T: Simd<f32, N = 4>>(v: T) ect..

if you already know both the length and element type then there's only one Simd type that matches, using a generic is just extra complexity for no reason, just use Simd<f32, 4> or the f32x4 type alias. this is similar to how you'd write [f32; 4] instead of T: Array<f32, 4>

[Keith-Cancel]

I guess that depends on what your doing/preference, I am just saying #[type_const] can allow for less verbose signatures.