Add saturating support

[danieltowner]

Intel's implementation does this too: https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2022/p0543r2.html

Add it to std::simd (as that link itself suggests)?

[mattkretz]

Yes 👍. We need overloads for simd<T> with the same constraint on T as in P0543. Note that P0543 just cleared LEWG and sits in LWG targetting C++26.

[danieltowner]

I will write this up as a proposal.

[danieltowner]

https://isocpp.org/files/papers/P2956R0.html

[mattkretz]

• The wording will need some work (not necessarily for LEWG review, I think). Maybe there's a better way to pull in all constraints and preconditions from foo_sat(T, T). Some "equivalent to" or so magic incantation... :-)
• The template parameter for saturate_cast needs a discussion. The direct equivalent would seem to be saturate_cast<simd<T>>(v) rather than saturate_cast<T>(v). I.e. we're casting to simd<T> not to T. I understand the desire for a shortcut and generic code. I'm undecided. The paper should explore both and guide a LEWG discussion & decision.

[danieltowner]

• The template parameter for saturate_cast needs a discussion. The direct equivalent would seem to be saturate_cast<simd<T>>(v) rather than saturate_cast<T>(v). I.e. we're casting to simd<T> not to T. I understand the desire for a shortcut and generic code. I'm undecided.

I think this is desirable in other places too, such as simd_bit_cast<T> and simd_cast<T>. All three cases read better and are more concise if you can just provide the new type of element, without having to figure out the simd sizes too and create a complete simd type. This is especially true for the bit cast where a new simd size might be needed.

For consistency, whatever we decide, then we should do the same in all three cases.

Users objected when I removed simd_cast from the Intel implementation, and they continue to grumble about it even now.

[mattkretz]

I fully understand the desire for casting to T instead of simd<T>. I mean, I needed it in several places myself and it's just so much simpler for generic code.

However:

1. This can't work with static_cast.
2. simd_cast can be special because it has simd in its name.
3. saturate_cast probably shouldn't be special because it does not have simd in its name.
4. I floated the idea of a representation_cast or value_type_cast (or whatever name) that generically works for all kinds of types to change their value_type. I think that would be nice to have.