As another wide user, thanks so much for this PR! I've been wanting to do this for forever but never found the time.
Just some drive-by thoughts/comments from me:

• Yes the mixed inherent and trait impls for Cmp... are currently very annoying. I'd say it's worth a breaking change to drop the inherent implementations.
• The macro-based tests sound like a good idea indeed. Would be great to check that all integer types support the same set of functions, and similar for float types.
• I don't know much about flaots, but recip_sqrt should probably use the intrinsic; that's what it's made for and this intrinsic is provided specifically because this operation can be done efficiently.
• mul_widen is called widening_mul in the standard library.
• Based on eg a044070, it looks like some functionality tests (not just does-it-compile tests) might be good?
• Oh this bug in u64x8::simd_lt was quite bad!
• You're adding a bunch of pub functions (like reduce variants). Should these be documented and/or moved into traits as well?

I don't have time to check closely on this today, but I will probably have time tomorrow. I like what I see so far.

i do like the macro test idea.

Its great to hear this PR is helpful! I am working on a crate that uses wide so i am filling all functionality i need.

Yes the mixed inherent and trait impls for Cmp... are currently very annoying. I'd say it's worth a breaking change to drop the inherent implementations.

About simd_... functions, there could be a better solution than removing the inherit functions. Instead it is possible to make the traits pub(crate), and add public inherit functions like:

impl ... {
    #[expect(private_bounds)]
    pub fn simd_eq<Rhs>(self, rhs: Rhs) -> Self
    where
        Self: SimdEq<Rhs>,
    {
        SimdEq::simd_eq(self, rhs)
    }
}

This solution would still support both SIMD values and scalars for the second argument. This seems like a good solution unless there is another use for these traits which i am missing?

I don't know much about flaots, but recip_sqrt should probably use the intrinsic; that's what it's made for and this intrinsic is provided specifically because this operation can be done efficiently.

About recip, base functionality like +-*/ and recip should probably be cross-platform deterministic and consistent with std, as use cases that require cross-platform determinism rely on these. On the other hand, initially i thought standard library recip always returns the infinite-rounded result, but it seems the documentation does not promise this, so i should check its results compared to 1.0 / x.

For recip_sqrt since std does not have it, if documentation is added about rounding errors it would probably be fine.

Based on eg a044070, it looks like some functionality tests (not just does-it-compile tests) might be good?

The result of unpack_lo/hi is indirectly tested via transpose. Since these functions don't have any edge cases i don't think direct tests are needed unless they become public.

You're adding a bunch of pub functions (like reduce variants). Should these be documented and/or moved into traits as well?

All functions added (unless i made a mistake) already existed for some types but were missing from others. For example, reduce_add already existed for i32x4 but not for i8x16.

Documentation is missing from the entire crate so maybe fixing that should be a seperate PR?

About traits, these functions should probably only be in traits if the entire API is moved into traits. That is possible, but personally i dislike the idea.

About simd_... functions

Hmm. Indeed I use wide::CmpGt::simd_gt and such a lot, but it seems I do not actually use the traits themselves as bounds, so removing the traits and using (generic) inherent functions might just be fine?

Maybe it would then be better to have a uNxL trait that encapsulates the common logic of all integer types, but that's a separate thing.

Possibility: If we change the existing inherent methods to take Into instead of Self, that wouldn't be a breaking change I think? Then we can have a From impl for scalar values into wide values. I think those From impls mostly already exist, but might not for all types.

I would like it to be totally uniform where possible, but unfortunately I would also like to avoid breaking changes. Maybe we can just do as much as possible for the 1.0 version, and leave an overhaul for 2.0 (which is, ideally, some time after the stdlib simd types become stable, and wide can be rewritten as being "just" an interface over stdlib types).

Rust lists this change as minor: https://doc.rust-lang.org/cargo/reference/semver.html#fn-generalize-compatible.

Inherit functions could be added using Into without making the original traits private. New users would not need to use the traits and previous code would be mostly non-broken (minor changes are always only "mostly non-breaking"). If this is the solution should the traits be deprecated?

I agree that it is a bad idea to make breaking changes especially because of std::simd. Tho if the std types get stabilized, is there a point to updating wide to 2.0.0? Previous code that wants to upgrade will need a refactor anyway so it would be better to upgrade directly to std::simd::Simd (unless the types are stabilized without all functionality).

Two more notes:

• The bound should probably be where Self: Cmp...<Rhs> instead of Rhs: Into<Self> because, even though this is a weird case, the traits can be implemented for third party types (impl CmpEq<ThirdPartyType> for f32x4).

• Should i add the macroed tests into this PR?

Let's put the macro tests into the PR now, let's put the method adjustment and trait thing on hold until a later PR. I'd rather just merge the stuff that we know is an improvement, and save the pondering.

u8x16 has similarly named functions unpack_low/high.

This is the Rust equivalent of SSE2's unpack_low_i8_m128i. This is basically unpack and interleave low (unpack_low) or high (unpack_high) lanes.

mul_keep_high

This is the Rust equivalent of SSE2's mul_i16_keep_high_m128i(see https://doc.qu1x.dev/nalgebra-spacetime/safe_arch/fn.mul_i16_keep_high_m128i.html).

Hope it clarifies these functions 😄.