> What I don't get is, why are we still adding more undefined behaviour to the standard? Why do you believe this is some kind of problem? Can you explain in co

> What I don't get is, why are we still adding more undefined behaviour to the standard? Why do you believe this is some kind of problem? Can you explain in concrete terms what issue you have with undefined behavior? > However, in C++, std::unreachable just invokes undefined behaviour when called. It does, by design and as a testament to great design choices. > It's not usable as a guard from programming errors, it's just an optimization hint. You still have to write the guard yourself. I don't understand what point you tried to make. Nothing in your comment has any relation with undefined behavior. Instead, you're complaining that in your personal opinion different languages have similar-sounding features that work differently. Oddly, you should really read up on std::unreachable, because one of the reasons explicitly stated in it's references is to "trap them to prevent further execution". To explain what this means in no ambiguous terms, the standard ensures that a) std::unreachable is valid C++ and made available to the world to have the semantics to specify that a code path is unreachable, and b) allow everyone to handle that as they see fit by flipping flags in the build system. Think about it for a second. You want to call std::abort when std::unreachable is hit. Great, go with that. I don't, and instead I want the compiler to optimize away that code path and anything it would touch, but on debug builds I want it to output a warning and trigger a breakpoint. Have you noticed that all these cases introduce behavior that's entirely different, arbitrary, and implementation-defined? How do you, as a standards committee, get to cover all possible use cases? By specifying it as undefined behavior. https://en.cppreference.com/w/cpp/utility/unreachable https://en.cppreference.com/w/cpp/utility/unreachable