3 ms·

I hope they took into consideration a corollary: that new code often _exposes_ bugs in the old, by exercising untested code paths or just by breaking assumption

I hope they took into consideration a corollary: that new code often _exposes_ bugs in the old, by exercising untested code paths or just by breaking assumptions. When a bug arises this way, do you attribute it to the new code or the old? A good takeaway is that the old code should not have exposed paths that didn't yet have a consumer. I frequently fall into the trap of making my code too general to support future use cases, and this usually ends up being rewritten when those use cases are actually implemented, or the code is just dead for the lifetime of the project.

tialaramex 4y ago
> When a bug arises this way, do you attribute it to the new code or the old? Rust has a hard rule here, if your code wasn't marked unsafe, but it can be (ab)used in a way which causes unsafety, then the code is wrong. If the code is marked unsafe, but the safety documentation misses a key requirement and as a result you can obey the documented safety rules and still get unsafe behaviour, that code or its documentation is still wrong. Thus in Rust it's never OK to say "You were using it wrong" on APIs unless they explicitly say they're unsafe and provide documentation on how to use them safely knowing that. Rust's sort() and sort_unstable() are trickier than the equivalents in the C++ standard library because a silly or erroneous Ord implementation like claiming to be Greater even than yourself is (stupid but) safe in Rust and must not induce unsafety in the sort() methods. In C++ 20 if your ordering constraints are bogus, you've got Undefined Behaviour immediately. Rust can't "correctly" sort six Ponies that all insist they're the Best Pony, but it can promise that attempting to sort them is safe. Obviously legacy code in a language with no hard rule about what's required may be more fraught, most C++ ought to be labelled "unsafe" but chances are it does not adequately document all the constraints on parameters etc. for safe use.

tialaramex 4y ago

> When a bug arises this way, do you attribute it to the new code or the old? Rust has a hard rule here, if your code wasn't marked unsafe, but it can be (ab)used in a way which causes unsafety, then the code is wrong. If the code is marked unsafe, but the safety documentation misses a key requirement and as a result you can obey the documented safety rules and still get unsafe behaviour, that code or its documentation is still wrong. Thus in Rust it's never OK to say "You were using it wrong" on APIs unless they explicitly say they're unsafe and provide documentation on how to use them safely knowing that. Rust's sort() and sort_unstable() are trickier than the equivalents in the C++ standard library because a silly or erroneous Ord implementation like claiming to be Greater even than yourself is (stupid but) safe in Rust and must not induce unsafety in the sort() methods. In C++ 20 if your ordering constraints are bogus, you've got Undefined Behaviour immediately. Rust can't "correctly" sort six Ponies that all insist they're the Best Pony, but it can promise that attempting to sort them is safe. Obviously legacy code in a language with no hard rule about what's required may be more fraught, most C++ ought to be labelled "unsafe" but chances are it does not adequately document all the constraints on parameters etc. for safe use.