Yeah, with modern C++, you can largely choose to avoid using elements that are prone to undefined behavior. For example, rather than native integers, you could use a compatible integer class that checks for division by zero [1]. Or one that checks for overflow too [2]. The Core Guidelines lifetime checker aims to (eventually) make native pointers and references memory safe via (severe, but not quite as severe as Rust) usage restrictions. And when you need to circumvent the restrictions, you can use an unrestricted smart pointer with run-time checking [3][4].
I agree, the problem is ensuring everyone at the company and third party dependencies, many of which available as binary libs only, do actually use those modern C++ constructs.
Interesting project; are you aware of any actual users?
Meanwhile, in the real world, C++ programmers typically use operator+(int,int) with UB on overflow because it's conveniently built into the language.
The problem with C++ isn't that doing the right thing is impossible, it's that doing the wrong thing is the default, with no dependencies and no syntactic overhead.
> Meanwhile, in the real world, C++ programmers typically use operator+(int,int) with UB on overflow because it's conveniently built into the language.
In more than a decade of coding with C++ I have never been bitten by a signed overflow bug which is UB. However I have been hit by unsigned underflow (e.g. if(2u - 3u > whatever)) way too often even though it is perfectly "legal" from the point of view of the language.