News for hackers. Stuff that matters.
Re:Safety vs. Performance. A case study of C, C++ and Rust s... by prosqlinjector on Thursday October 05, 2023 @09:12PM (#37786177)
> If I'm reading the article correctly, the user can be informed at runtime with little to no performance impact.

It's not possible to verify a function is a strict weak ordering without enumerating the entire domain.

Re:Safety vs. Performance. A case study of C, C++ and Rust s... by itishappy on Friday October 06, 2023 @01:43AM (#37787449)
Right, but restricting the domain to just the list you're already enumerating makes things easier.
Re:Safety vs. Performance. A case study of C, C++ and Rust s... by prosqlinjector on Friday October 06, 2023 @01:24PM (#37793510)
Yep, so now your sort function isn't just a sort. It's a sort with a unit test at the beginning. This burden is placed on EVERY use.
Re:Safety vs. Performance. A case study of C, C++ and Rust s... by Voultapher on Friday October 06, 2023 @03:24AM (#37788048)
I'm not sure enumerating the entire domain is even possible in this setting, as the comparison function could return random values for each call.

The idea is that the implementation doesn't promise it will detect a strict weak ordering violation, but it has code that will detect the effects of such violations with a high probability. It's not a sampled approach, but rather as part of the small-sort a bi-directional merge is performed and if the pointers don't line up, the only explanation is a strict weak ordering violation, the result of the merge is discarded and a panic is raised.