On Thu, Feb 19, 2026 at 11:54 AM Andrey Semashev via Std-Proposals <
std-proposals_at_[hidden]> wrote:

> 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.
>

I have concerns about this feature even if it is never used in libraries.
If I am a library author and one of my users uses `compile_assert` in their
code, but the value of the predicate was obtained directly or indirectly
from a use of the library (and the compiler was able to prove its truth by
inlining the library call), and I then change the implementation of my
library, that `compile_assert` can start failing because the optimizer can
no longer prove the property of the library call that the `compile_assert`
is checking.

If you are both the author of the library and its main user, you may
consider this outcome desirable, as you've now discovered that your new
implementation is harder for the optimizer to understand, which is an
undesirable aspect of it that you wish to mitigate by going back to the
drawing board.

However, within a large organization where a library has hundreds of users,
it seems to me that if `compile_assert` proliferates, the existence of
those `compile_assert`s in user code will become a major maintenance
headache. Having the new implementation be greater-than-or-equal-to the old
one in "optimizability" every time the library needs to be refactored
cannot be allowed to become a release-blocking requirement, as it must be
traded off against other considerations. Therefore, there is a strong
argument for banning this feature organization-wide if it were to become
part of the standard.


>
> --
> Std-Proposals mailing list
> Std-Proposals_at_[hidden]
> https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals
>

-- 
*Brian Bi*