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.

My 2 c,

-- 
Giuseppe D'Angelo