shift_elements_{left,right}

[sammysheep]

This implementation was patterned after the pre-existing rotate_elements_{left,right} and is meant to supersede #112 from 2021. If this functionality is buried somewhere else in the API that I missed, please close with a note where I can find it.

The tests pass and the assembly looked reasonable on x86.

[calebzulawski]

Not to say we shouldn't have this function, but (devil's advocate) slices for example only have rotating elements, not shifting in default. You could technically use our already implemented SIMD rotates, and then another swizzle to insert the default values.

Should this maybe shift in an arbitrary value, rather than Default?

[sammysheep]

Ah, this PR came about because I wrote an extension trait to do this for an algorithm that needs to shift by one element to the left and continue on its merry way. The C code I was porting just used a single intrinsic for what amounts to the same thing, so that motivated me to look for it in portable SIMD's API.

Perhaps also, adding an explicit shift_elements function might help users to stop and realize that the Shl / << operator works within each element bitwise and not element-wise. This was an actual mistake I made a few months ago and only realized it after restarting my port project again yesterday. You /can/ use rotate++ as you suggest, but I wrote the extension trait exactly because my doing so would have felt like the wrong level of abstraction.

As to using default(), the previous impl in #112 inspired me that it was an easy and natural way to provide zero-padding. However, I'm not stuck on that. If one were to make the pad value arbitrary, would it just need to be another const parameter I suppose?

If so, would that rule out things that are invalid as a const generic parameter like f64?

Happy to make whatever desired changes based upon your own design goals if you decide to keep this PR.

[programmerjake]

However, I'm not stuck on that. If one were to make the pad value arbitrary, would it just need to be another const parameter I suppose?

no, it can just be a function argument, no need for it to be const.

[sammysheep]

I have changed it to accept a padding argument and updated the tests and docs. This seems equivalent for the zero case on x86_64: https://godbolt.org/z/E8h9onese