Sure, but “better than nothing” is already an improvement on what we have today with the tools we have today and with much smaller impact than what is proposed here.
The check that you propose adds close to zero value (it doesn’t guarantee anything at all), while having a cost, that is, it would need to be a
debug_assert! check, which means that users would need to deal with two versions of the standard library and all their dependencies, one compiled with
debug_assert! and one without.
Once we are there we might just offer a fortified build with checks that actually address the problems that they were supposed to solve.
I think nobody is going to run their software with those checks enabled by default. […] Where do you see this being useful?
I’ll run them in all my debug builds by default during development to catch logic errors early.
Especially if such kind of checks get littered throughout the standard library and you might end up with some inadvertent quadratic blowups.
I don’t care about worse algorithmic complexity in debug builds as long as doing so adds some value. If the checks are very expensive, like this one, I would like to be able to opt into them, but that’s about it. Also, given the current state of the complexity guarantees of the standard library algorithms, it would seem that many don’t care about this on release either.