This is a super interesting approach I hadn’t thought of. Unfortunately it seems to be limited in practice, as demonstrated by the article: first of all, certain constructs cannot be used in a constexpr context, and second (and more worryingly) many compilers fail to diagnose undefined behavior or do so incorrectly. If the second issue can be fixed I can see this being a very useful, if specialized tool for improving the safety of C++ code.
> certain constructs cannot be used in a constexpr context
yet. endgame is to make mostly everything constexpr-able. constexpr dynamic_cast, try/catch, and virtuals are coming in C++20 for instance and there are papers to get constexpr memory allocations in C++23.
> many compilers fail to diagnose undefined behavior or do so incorrectly.
It would be much easier if undefined behaviour was better defined, because then a compiler could recognize it and diagnose it. Of course then it wouldn't be undefined behaviour any more, so problem solved.
The bounds of what consists undefined behavior is, well, defined. The “undefined” bit refers to the behavior in this case, not its ability to be recognized.
