Date: Thu, 19 Feb 2026 19:23:02 +0300
On 19 Feb 2026 18:32, Ville Voutilainen via Std-Proposals wrote:
> On Thu, 19 Feb 2026 at 17:28, Jonathan Grant via Std-Proposals
> <std-proposals_at_[hidden]> wrote:
>>
>> Hello
>>
>> On 19/02/2026 15:11, Andre Kostur wrote:
>>> Does this mean that this can/will behave differently depending on what
>>> optimization levels you may have enabled on the compiler? -O3 and it
>>> can pass the compile_assert(), -O0 and the compile_assert() fails?
>>> If so, this could be troublesome in the context of the Standard since
>>> it doesn't currently acknowledge "optimization levels".
>>
>> Hello Andre
>>
>> if __OPTIMIZE__ is not defined, the compile_assert() macros all compile out.
>>
>> I've not compared eg -O1 and -O3 to know of any differences, but you're right there might be. The errors may end up very compiler and optimizer specific (gcc vs clang etc), it may not be possible to have all compile_assert() desired with a particular compiler.
>> -- In which case, I would achieve the check another way (ie very close to the line of I am concerned about), or treat as a human review, and put in some mitigations and error handling by myself (and a test function to trigger a fault while running, an overflow etc and check detected), compile_assert() isn't suited to everything.
>
> All that is both an issue with this tool, and also the beauty of it.
>
> Once you have changed your code sufficiently that compile_asserts
> pass, when they didn't before, you have changed your code so that it
> can be locally-reasoned.
> Both by humans and tools.
>
> That's amazing. That's fantastic. That's wonderful.
I don't see it this way. Mangling valid code only to help the compiler
prove the asserts, possibly harming maintainability and performance, is
not amazing at all. Add to that the portability aspect, where you might
have to mangle the code differently for different compilers and the
usefulness of this feature goes down fast.
Imagine a library that is using compile_assert. As a user, how you are
supposed to use it, if the compiler is not able to prove all the
compile_asserts? As a maintainer, what are you supposed to do when users
start complaining about the failing asserts on their compilers? What if
the users do indeed want to compile their (and your) code with
optimizations disabled, e.g. to debug a problem? This would be a
terrible idea.
> On Thu, 19 Feb 2026 at 17:28, Jonathan Grant via Std-Proposals
> <std-proposals_at_[hidden]> wrote:
>>
>> Hello
>>
>> On 19/02/2026 15:11, Andre Kostur wrote:
>>> Does this mean that this can/will behave differently depending on what
>>> optimization levels you may have enabled on the compiler? -O3 and it
>>> can pass the compile_assert(), -O0 and the compile_assert() fails?
>>> If so, this could be troublesome in the context of the Standard since
>>> it doesn't currently acknowledge "optimization levels".
>>
>> Hello Andre
>>
>> if __OPTIMIZE__ is not defined, the compile_assert() macros all compile out.
>>
>> I've not compared eg -O1 and -O3 to know of any differences, but you're right there might be. The errors may end up very compiler and optimizer specific (gcc vs clang etc), it may not be possible to have all compile_assert() desired with a particular compiler.
>> -- In which case, I would achieve the check another way (ie very close to the line of I am concerned about), or treat as a human review, and put in some mitigations and error handling by myself (and a test function to trigger a fault while running, an overflow etc and check detected), compile_assert() isn't suited to everything.
>
> All that is both an issue with this tool, and also the beauty of it.
>
> Once you have changed your code sufficiently that compile_asserts
> pass, when they didn't before, you have changed your code so that it
> can be locally-reasoned.
> Both by humans and tools.
>
> That's amazing. That's fantastic. That's wonderful.
I don't see it this way. Mangling valid code only to help the compiler
prove the asserts, possibly harming maintainability and performance, is
not amazing at all. Add to that the portability aspect, where you might
have to mangle the code differently for different compilers and the
usefulness of this feature goes down fast.
Imagine a library that is using compile_assert. As a user, how you are
supposed to use it, if the compiler is not able to prove all the
compile_asserts? As a maintainer, what are you supposed to do when users
start complaining about the failing asserts on their compilers? What if
the users do indeed want to compile their (and your) code with
optimizations disabled, e.g. to debug a problem? This would be a
terrible idea.
Received on 2026-02-19 16:23:05