On Wed, 12 Apr 2023, 13:04 samuel ammonius via Std-Proposals, <
std-proposals_at_[hidden]> wrote:

> On Wed, Apr 12, 2023 at 12:57 PM Giuseppe D'Angelo via Std-Proposals <
> std-proposals_at_[hidden]> 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_at_[hidden]
> https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals
>