Yes, this is one of the advantages of pervasive operator overloading in C++. You can create types that behave like primitive integral types for all practical pu

Yes, this is one of the advantages of pervasive operator overloading in C++. You can create types that behave like primitive integral types for all practical purposes but which implement alternative behaviors like trapping overflow, blocking integer promotion, defining shift operators greater than or equal to the bit width, creating alternative casting rules, etc. However, it has not always been possible to implement this transparently in C++. This did not work well in older versions of C++ because the limited type inference meant that many common cases around different type interactions required explicit handling that made it clear you were not using native types. Around C++17 it became possible to define integer types that were almost entirely indistinguishable from the native types in ordinary C++ code. C++17 was important because it meant a lot of safety in the code base could become automagic via the type system, especially for primitive types. The code looks the same whether you are using it or not. That was a huge capability change. C++20 then generalized it to arbitrarily complex types. It is difficult to overstate how much this improves the conciseness and safety of non-trivial code.