Comment by wongarsu
4 days ago
I would phrase the difference between contracts and input validation like this:
- If it can happen, but shouldn't, that's input validation (e.g. the user inputs an empty name)
- If it can't happen and shouldn't, that's a contract (e.g. I checked that this string is non-empty in the function that calls this one, so I already know it's non-empty. Also my linked list has a head and a tail because that's how my constructor made it)
Most bugs happen in the space of things that the programmer thinks shouldn't happen but happen anyways. That is why contracts are useful. But in a bug-free program they also don't do anything, so allowing you to turn them off with a compiler flag is reasonable. Just like asserts, but a bit more useful for tooling, IDEs, etc. Also with an observe mode that allows you to find bugs in production without crashing your whole process
FTFY: "Most bugs happen in the space of things that the programmer thinks can't happen but happen anyways". I'm sure we all have stories about some baffling error that simply couldn't have occurred, it's impossible, and then you spent an hour staring at the code, reading the tracing logs, and then finally finding a single-character typo responsible for it. Whoops, it's not supposed to be "if (p != nil) { return false; }", it's meant to be "if (p == nil) { return false; }"!
But yeah, that's precisely what contracts are (at least originally) intended to be, but you can quite clearly see from this comment section that this is not how they're going to be used. Well, this surely gonna be "fun" experience down the line for the C++ programmers...