[kazinator]

Tying asserts to optimization is bad design. Asserts are for debugging; you write an assert when you are not 100% confident that it holds, or there is a risk of it not holding in the future even if it holds now.

The "assert" word is not a great choice, but it's entrenched that way. In a debate, you'd not want to assert something (present it as a fact) if you're not sure.

Optimization promises have the same form; they are also assertions, but with a different purpose. They can use the same syntax, but some different word.

The word assert is attractive for this purpose: I know for sure something is true, and I'm communicating it to the compiler; thus, I am asserting something.

The designer must not be thereby seduced into conflating debugging assertions with optimization promises.

I understand that in this case they have a safety switch for assertions, but conflating debug assertions with optimization promises by means of a switch is still a poor design.

You want that switch on a case-by-case basis for each individual assertion, and the easiest way for that is to just have a different identifier.

[aw1621107]

To add on to this, the C++ proposal for [[assume]] [0] came to a similar conclusion and cites MSVC's experience with an assert-in-debug-assume-in-release construction (i.e., removing the assumptions resulted in a 1-2% speedup and increased reliability) as a reason to not tie assertions to assumptions.

[0]: https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2022/p17...

[1]: https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2020/p20...