On 19 Feb 2026 19:41, Ville Voutilainen wrote:
> On Thu, 19 Feb 2026 at 18:23, Andrey Semashev via Std-Proposals
> <std-proposals_at_[hidden]> wrote:
>>> 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.
>
> I can imagine all sorts of things, including imagining that some
> programmers can use the right tool for the right
> job, and don't just mindlessly sprinkle every language feature
> everywhere in their code, and then complain
> that some such language feature was a terrible idea. :D

So are you saying that this feature is not intended to be used in
libraries then? Because the way it is specified, I cannot see how it
could be reliably used. If so, then yes, this feature is a terrible idea
and DOA.