Implement traits over scalars with self: Simd<T, N>

[calebzulawski]

This PR has been overhauled a little bit because we decided to try using self: Simd<T, N>.

Original comments:

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

[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.

[programmerjake]

we spawned a discussion: https://rust-lang.zulipchat.com/#narrow/channel/257879-project-portable-simd/topic/Simd.20traits.20and.20assoc.2E.20.60type.20const.60.20vs.2E.20other.20API.20designs/near/592861697

[programmerjake]

after thinking some more, I think I found the best API so far: https://rust-lang.zulipchat.com/#narrow/channel/257879-project-portable-simd/topic/Simd.3CT.2C.20N.3E.3A.20Receiver.3CTarget.20.3D.20T.3E/with/593431978

[rustbot]

This PR was rebased onto a different master commit. Here's a range-diff highlighting what actually changed.

Rebasing is a normal part of keeping PRs up to date, so no action is needed—this note is just to help reviewers.

[programmerjake]

generally looks good to me, though we'll want to wait on rust-lang/rust#156270 before merging.

View changes since this review

[rustbot]

☔ The latest upstream changes (possibly #533) made this pull request unmergeable. Please resolve the merge conflicts.

[workingjubilee]

So this looks fine and my only primary question atm is the detail of why the const N is in every function instead of a generic as part of the trait definition per se. Though as I believe has been mentioned it might be better off as an associated constant of sorts but we don't want to expose that immediately because of mGCA stability concerns?

My primary question probably has an answer that has already been converged on and I missed it in the discussion, apologies.

View changes since this review

[calebzulawski]

So this looks fine and my only primary question atm is the detail of why the const N is in every function instead of a generic as part of the trait definition per se. Though as I believe has been mentioned it might be better off as an associated constant of sorts but we don't want to expose that immediately because of mGCA stability concerns?

My primary question probably has an answer that has already been converged on and I missed it in the discussion, apologies.

In short having it on the function means you can do T: SimdUint and then use Simd<T, 4> and Simd<T, 8> without introducing new bounds, because "being able to be put in a Simd" is a characteristic of the scalar. It's not strictly necessary, but it will be easier when we get to things like <T as SimdFloat>::Bits being independent of the vector size.