Making simdeez safe

[arduano]

While working with SIMD and looking around for various libraries (before I took over maintenance), one of the main criticisms I've seen for simdeez is that the api it exposes is unsafe. And yeah in one of my larger projects where SIMD is used a lot and passed between different structs, having most operations be marked as unsafe gets fairly annoying when I'm certain that the code should be safe.

From what I can tell, the only reason the api is unsafe is that there's no guaranteed way to make sure the cpu supports the instructions at the time the functions are called. The only time we can guarantee what the cpu supports is when we use the runtime generate function. Does that sound correct?

If we adhere to the above, then we can make the API safe by following the following:

• We can keep the unsafe types (Sse2, Avx2, etc) as-is, but also make safe variants of them which are private and only accessible inside simdeez, but they all share the same Simd trait as well as a SafeSimd trait and can still be passed as a generic into functions.
• Runtime generate and compiletime generate pass in the safe trait rather than the unsafe one, and still perform runtime checks to ensure that the initial function call operation is valid. If it isn't, it panics.
• Basically, an instance of the SafeSimd generic trait can only exist if it was validated at runtime.

I'm not completely sure how feasible this would be, however one approach we could take for making the safe structs "private" is by prefixing the module and the struct names with a bunch of underscores and leaving various warnings that using them directly is unsafe.

The end goal is to just have purely generic SIMD while having peace of mind that it's definitely safe. Something that it feels like this library is missing.

If done well, I don't think it would have major api changes to existing users too.

[arduano]

@jackmott @verpeteren just curious about your input before I commit to further exploring this possibility.

[jackmott]

The intrinsics are fundamentally unsafe. But if our API ensures that it is impossible for someone to use them in an unsafe way, then it is fine to expose the API as a safe one. If we could guarantee a crash on startup if the instruction set being used isn't present, then that might be good enough to resolve the instruction existence issue. Similar to crashing if you run out of memory in safe rust?

[arduano]

Yeah by runtime checks I meant panicking on the parent function call, the one generated by the macro