> You're regretting it because No, I'm regretting it because having to spend hours replying to comments that ignore the premise is a complete waste of my time.

> You're regretting it because No, I'm regretting it because having to spend hours replying to comments that ignore the premise is a complete waste of my time. > you keep telling people to use an interface that explicitly was designed to not provide bounds checking As a matter of fact it was very intentionally and specifically designed to allow bounds-checking to be configured at build time: "As an example, in the current reference implementation, violating a range-check results by default in a call to terminate() but can also be configured via build-time mechanisms to continue execution (albeit with undefined behavior from that point on)." [1] Calling that "explicitly designed not to provide bounds checking" is quite a deceptively misleading way to paint it. It's not an accident that you can enable bounds-checking, it's very much by design and intended that you do so. They just didn't happen to standardize the flag name, just like they never standardized the optimization flag names. > and claiming that this is the solution to make their code safer, while in reality you have to look up some nonportable flag to enable it for your STL if even offers the functionality at all. Like I said, this is literally the same as optimization flags. Everybody passes them and nobody bashes C++ for it. You're making a big deal out of something incredibly tiny just to win an internet argument on the wrong thread. [1] https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2018/p0122r7.pdf https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2018/p01...