This is long overdue. Platform intrinsics have had _mm256_castps_si256 forever - same bits, different element type, zero overhead. std::simd made you spell out the entire target type with manual count computation. bit_cast_as<uint32_t>(floats) is the natural C++ equivalent and it's embarrassing we didn't have it from the start.

The compile-time size verification is the key feature. bit_cast_as<uint32_t>(vec<uint8_t, 15>) won't compile because 15 bytes doesn't divide evenly into 4-byte elements. You catch the error at compile time instead of at runtime or in a code review.

The generalization to std::array is natural and useful. bit_cast_as<uint16_t>(std::array<uint8_t, 16>) returning std::array<uint16_t, 8> is exactly what protocol parsing code needs. The std::span variant returning a view (not a copy) is the right semantic choice too.

Depends on P3983R0 for array-like layout guarantees in simd. Without guaranteed contiguous element storage, bit_cast between simd types isn't portable. The dependency is well-documented and the prerequisite paper is in the pipeline.

bit_cast_as vs as_elements - the paper chose bit_cast_as because the relationship to std::bit_cast should be obvious. I agree. When you see bit_cast_as you know this is bit-level reinterpretation, not a semantic conversion.

Intel's simd implementation has had this internally since early development. It's widely used both in the library internals (interfacing with compiler intrinsics) and in user code (wireless signal processing, packet handling). Production-tested.