Sorry, no. There is no nuance around this. It should 100% be an error by default. It’s undefined behavior and there are justifiable reasons for being so. Requi

Sorry, no. There is no nuance around this. It should 100% be an error by default. It’s undefined behavior and there are justifiable reasons for being so. Requiring otherwise implies that implementations must exhaustively check every code path in a function. Such an analysis is extremely expensive, and even practically impossible for sufficiently complicated code, it also would need to work across translation units, e.g. akin to whole program optimization. Not to mention cases like linking against a binary library in which the compiler has nothing to analyze at all, or when a functionally impossible non-return path is found but the compiler can not prove to itself that it’s unreachable. Ultimately there are situations in which non-void functions do not have a return value. Moreover, it is certain that a non-trivial amount of code is relying on such behavior. Therefore is unreasonable to make implementations non-conformant and it’s impossible to decide what a reasonable behavior should be otherwise, hence the behavior being undefined. As an intermediate step they can at least specify the sized of types that are de facto fixed. Why hurt non-standard platforms and encourage the use of poorly named integer types? Anyone who cares about this is already using fixed width types. Sigh. Well it's good that I don't have to deal with this attitude in Rust at least! Oh, and Rust doesn’t recommend using linting or code formatting tools like clippy or rustfmt? By all means, use Rust if it’s an option for your needs. C++ is a very old language with all sorts of compromises.