Hi Brian

On 19/02/2026 23:07, Brian Bi via Std-Proposals wrote:
>
>
> On Thu, Feb 19, 2026 at 11:54 AM Andrey Semashev via Std-Proposals <std-proposals_at_[hidden] <mailto: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] <mailto: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.
>

Many thanks for sharing the example. It could happen, if the library code became very complicated. I've not seen it yet, but if you have any example of a way a function could become more complicated so is no longer handled by the optimizer. I usually use for very straight-forward things, like array access index bounds checks, or nullptr.


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

Sometimes I use just a few functions, so they could be turned off by an empty macro and never inconvenience anyone:

#define compile_assert(condition, description)

Sometimes I just use it during code reviews, to check things (ie it is not left committed).

Regards
Jonathan