On Wed, 12 Apr 2023, 12:18 Jason McKesson via Std-Proposals, <
std-proposals_at_[hidden]> wrote:

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

The expression has defined behavior if a and b are sub arrays of the same
multidimensional array. Or if they are the same array, but I repeat myself.

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

+1 (pun not intended).

>