On Wed, Apr 12, 2023 at 11:27 AM Giuseppe D'Angelo via Std-Proposals
<std-proposals_at_[hidden]> wrote:
>
> Il 12/04/23 17:12, samuel ammonius via Std-Proposals ha scritto:
> > On Wed, Apr 12, 2023 at 12:20 PM Giuseppe D'Angelo via Std-Proposals
> > <std-proposals_at_[hidden] <mailto: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
> > <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.
>
> Sorry, when you say "that's not" <- what's "that"?
>
>
> > If it's already UB then why work to keep it stable?
>
> That is another question -- it's still a source break, though
> (`decltype(a-b)` changes.)
>
> >
> > 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),
>
> Again, what's "that"? The decay?
>
>
> > 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.
>
> It is certainly a huge change. What should `+a` do? This is _widely_
> used as an idiomatic "please decay". Should it stop decaying and give
> back the float[4] unchanged?
>
> What should `a + 3` do? This has well defined semantics and it's _super
> widely_ used. Are you suggesting to break that code?
>
> What should !a do?
>
> And it's not just about the operators themselves: how do you pass a SIMD
> float[4] to a function? How do you return one from a function? Today a
> function like `void f(float[4])` has a precise meaning (that has nothing
> to do with SIMD).
>
>
> IMVHO: we should be killing C-style arrays, not adding more features to
> them.

The other elephant in the room is that SIMD often requires specific
alignment for its objects. And C arrays don't come with that; you'd
have to explicitly align them with `alignas`. Which means you now have
to know what alignment to use for the platform, or to use some type
that provides the alignment (which will often require you to restate
the size of the array).

Whereas with a proper, dedicated type, alignment comes for free.