On Wed, 12 Apr 2023, 13:04 samuel ammonius via Std-Proposals, <std-proposals@lists.isocpp.org> wrote:
On Wed, Apr 12, 2023 at 12:57 PM Giuseppe D'Angelo via Std-Proposals <std-proposals@lists.isocpp.org> wrote:
Again, what's "that"? The decay?
 
Yeah, by "that" I was referring to the decay. It is UB, right?

Decaying an array is not UB. UB occurs when arithmetic between pointers involves pointers that do not point to elements of the same array. 


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?

I've never seen code that adds to an array to decay it in my life.

It's a very common idiom to get a pointer to the 4th element of the array. 

Anyway, I wasn't proposing that adding a number to the array adds it to every element (although I would have if I thought of it, but if it creates issues then lets not add it).

Then we have a confusingly incomplete feature. 


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).
 
Functions that take arrays can just perform SIMD on the passed array. About returning SIMD, it's the same issue as returning arrays. I don't know why we can't return arrays since computers are perfectly capable of doing that.
--
Std-Proposals mailing list
Std-Proposals@lists.isocpp.org
https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals