The problem with this is that the usage of safe<int> changes the meaning of the program.
int i; // i not initialized .... // program has weird behavior
In this particular case, the fact that the program was relying on UB means that the program had no meaning at all. So it adds a meaning maybe :) However I see your point ; you expect people to do something like: #ifdef DEBUG typedef safe<int> my_int; #else typedef int my_int; #endif But, you could instead market the following usage: #ifdef DEBUG typedef safe<int, SomePoliciesWithRuntimeChecks> my_int; #else typedef safe<int, SomePoliciesWithOnlyCompileChecks> my_int; #endif IMHO, it makes no sense to design your library to allow users *not* using it. If it is possible to disable some or all the runtime checks, the users has no excuse to just switch to builtin types. Moreover, the incentive to switch *from* builtin types is higher, as users can choose to do it gradually: First all our integers will be initialized and compile-time checked, then we can add runtime checks in debug mode, and finally, we can bench the whole thing with the runtime checks in release builds. My 2 cents,