Can this feature proposal be lifted from a best-effort base to be reproducible? Something like preconditions contracts, which have to be provably be true at compile-time. Can there be hints to guide the compiler to a deterministic proof?   -----Ursprüngliche Nachricht----- Von:Brian Bi via Std-Proposals <std-proposals_at_[hidden]> Gesendet:Fr 20.02.2026 00:07 Betreff:Re: [std-proposals] compile_assert() a static assert that fires at compile time, not runtime. An:std-proposals_at_[hidden]; CC:Brian Bi <bbi5291_at_[hidden]>; 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.