not sure I agree. UB has the benefit that there are a lot of tools like valgrind, memcheck, and various compiler features to detect it both statically and at runtime. And when you hit UB it is certainly an error.

Non-UB errors have no such powerful tools, only what application specific tests or assertions you create.

I've seen plenty of cases where people went and turned signed types into unsigned because signed overflow is undefined, but it had the real effect of turning easily detected and diagnosed issues into much harder to find bugs.

Also like, it's not universally true that UB bugs (broad class of problems) are all harder to debug than non-UB bugs (another broad class of problems). Null pointer dereferences are UB, and among the easiest class of problem to debug.

The practical ramifications are often similar, even if UB can in theory do anything.

It’s pretty common to implement graphs in terms of arrays, not because of indices but because of cache locality.

So your “UB” and “non-UB” code would look effectively identical to the CPU and would take the same amount of debugging.

The reality is whether an index was tombstones and referenced or “deallocated” and referenced it is still a programmer fault that is a bug that the compiler could not catch

> So your “UB” and “non-UB” code would look effectively identical to the CPU and would take the same amount of debugging.

Said the person who has never had to debug serious UB...