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