On 8/19/26 11:05, Ville Voutilainen wrote:
> On Wed, 19 Aug 2026 at 12:03, Jens Maurer <jens.maurer_at_[hidden]> wrote:
>>
>>
>>
>> On 8/19/26 05:37, Ville Voutilainen via Std-Proposals wrote:
>>> On Wed, 19 Aug 2026 at 05:54, Sebastian Wittmeier via Std-Proposals
>>> <std-proposals_at_[hidden]> wrote:
>>>>
>>>> If P2900 is staying, can you define (= propose) a 5th mode that acts like compile_assert and also hope that the implementations give better error messages and locations than an undefined violation handler?
>>>
>>> I don't know about others, but yes, yes I can: https://godbolt.org/z/xPz8hjcYY
>>
>> While this is all great experimentation, I'd like to point out that we'd
>> need an actual specification of what this new thing should do, instead of
>> "whatever the optimizer can deduce in today's version of my implementation".
>
> Sure, all in good time. It's not based on what the optimizer can deduce, at all.

Good to hear.

For your particular godbolt example, I notice that v.size() returns a size_t,
which is unsigned, causing conversion to unsigned values across the conditions.
The if-condition is thus wrong for "use_sound", because
v.size() == 1 and idx == 5 yields "large unsigned number" > 10",
which is unexpectedly true.

Jens