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.

That the resulting type of that expression is `ptrdiff_t` is
well-defined (that is, `decltype(a - b)` is well-defined). The *value*
of that expression (or rather, what happens when you execute it) is
UB.

> 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.

Again, the decaying behavior is already well-defined. You can't just
change that without ransacking the language.

Also, if you want to support SIMD, you also want to support something
like `a + 1`, where `1` gets broadcast to all of the elements in `a`.
And that is already well-defined, both in return type and in terms of
behavior.