> Even the C people glibc and LLVM libc consider this to be undesirable and are willing to spend 2-3% overhead on making sure you don't get that behavior.

libc++ actually had to roll back a std::sort improvement because it broke too much code that was relying on bad comparators. From the RFC for adding comparator checks to debug libc++ [0]:

> Not so long ago we proposed and changed std::sort algorithm [1]. However, it was rolled back in 16.0.1 because of failures within the broken comparators. That was even true for the previous implementation, however, the new one exposed the problems more often.

[0]: https://discourse.llvm.org/t/rfc-strict-weak-ordering-checks...

[1]: https://reviews.llvm.org/D122780 (not the original link, but I think this is the review for the changeset that was rolled back)

It looks more like an implementation error to me, and actually it looks more like a design mistake than an implementation choice because there are arguments in favor of using an abstract functor class for the comparison function (you'll need a closure sooner or later), which would have given the chance to warn the user about this particular issue in the docs - at least it would have been more visible and clearer than it currently is [1].

Because until vibe coding becomes a culture, programmers are at least expected to "RTFM". But that's also a requirement which is becoming harder to meet by the year, because - you almost said it the first few minutes of your talk - "we needed to merge it ASAP".

This mistake seems to have been somewhat fixed in C++20 [2]. "Too little too late", yes, probably.

[1] https://en.cppreference.com/w/cpp/algorithm/sort.html

[2] ibidem, tacit use of std::less.