On Wed, Apr 12, 2023 at 11:13 AM samuel ammonius via Std-Proposals <std-proposals@lists.isocpp.org> wrote:
On Wed, Apr 12, 2023 at 12:20 PM Giuseppe D'Angelo via Std-Proposals <std-proposals@lists.isocpp.org> wrote:
It's also a "language API break" (?) -- at the moment, `a - b` actually
compiles and yields ptrdiff_t, not float[4]. (But if you actually
evaluate it, it's UB https://eel.is/c++draft/expr#add-5.3 .)
But that's not what the standard says, that's just what most compilers have decided to do. If it's already UB then why work to keep it stable?

If the platform doesn't have SIMD then the compiler can just turn it into a loop. I think that was the plan for the existing SIMD proposal too. The language change itself isn't that big of a change either. Using math operations on arrays was never possible (other than how arrays decay to pointers that can be treated like integers, but that's UB), so this is just an addition to the language. I think it would also be pretty easy for compilers to implement since it's just mixing concepts that they already support.

Look up "operator overloading" — C++ already allows you to create a class type and overload its operators to get exactly the effect you want.
The trick, as everyone's saying, is not coming up with syntax; C++ already has plenty of syntax. The trick is being able to guarantee just by looking at the code that SIMD/vectorization optimizations are actually being applied. If you write (a + b) and the compiler quietly codegens a loop, then the tool has failed the one job it had: generating SIMD. That's why these SIMD "mini-languages" exist.