On Wed, Apr 12, 2023 at 11:13 AM samuel ammonius via Std-Proposals <
std-proposals_at_[hidden]> wrote:

> On Wed, Apr 12, 2023 at 12:20 PM Giuseppe D'Angelo via Std-Proposals <
> std-proposals_at_[hidden]> 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.

–Arthur