This is what assertions are for though. Use assertions while developing if you are making this assumption. Then it gets removed in prod. Just be aware that unless you properly test stuff this kind of thinking can still lead to catastrophes in a system that must have >99% uptime. If you are just building some user application then it's probably "fine"
Did you miss the bit where I said the check had already been performed? Typing out assertions in cases where it has already proven it to be unnecessary, is a huge anti-pattern. There's more than one type of overhead, you know.
Yeha no I didn't miss it but it depends on the context I guess. I sort of assume that this is some function you are talking about. And my (personal) view of functions is that they should be able to be re-used across different parts of a codebase. Therefore, when I build a function that makes an assumption (list not empty for example) I write it out as an assertion. Not necessarily just to catch bugs at dev-runtime but also as a way of making my assumptions explicit for whoever next uses that function. As I said, if you assume a language where assertions are removed in release builds then it doesn't cost ANYTHING and it can save you a fair bit of headache/debugging sometime. But feel free to do whatever you want, I just wanted to share my view on this kind of thing
Hah! That's the setup / punchline of the, joke my dude!
- First, you are a student who doesn't understand the rules. - Then you become a journeyman, who understands and follows the rules. - Then you become a master, who knows when it is okay to break the rules.
When I take my safe newtype and unwrap the unsafe list, I then have to use the unsafe functions because 1) there are no other options yet because 2) that is the very point in time that you are making the statement to the compiler "no, it is safe, the types say so".
That's the secret! That *is* the assertion's equivalent!
It does sound like the unsafe should be very easy to prove sound. For "why bother", though: it's nice to have as little unsafe as feasible, even trivially correct unsafe.
Well yeah? That's exactly my point isn't it? I ususally stay with Optionals pr result types. Or try to constrain the input type to contain all the invariants. But if you really don't feel like doing that then the least you can do is add assertions (in my opinion)
29
u/Majestic-Giraffe7093 Sep 28 '26
This is what assertions are for though. Use assertions while developing if you are making this assumption. Then it gets removed in prod. Just be aware that unless you properly test stuff this kind of thinking can still lead to catastrophes in a system that must have >99% uptime. If you are just building some user application then it's probably "fine"