4 ms·
Totally agree. That's kind of what I was going for when I described the hypothetical "true-strict" mode: don't allow the code I'm writing to do bad/unsafe stuff
by ragnese 5y ago
Totally agree. That's kind of what I was going for when I described the hypothetical "true-strict" mode: don't allow the code I'm writing to do bad/unsafe stuff.
And yes, I really wish that TypeScript's non-null assertions actually included a runtime check. Type casts can't really do anything at runtime without a definition of what "being type Foo" actually means, since the types are erased, but you can definitely check if something is null or undefined and throw an error.
I think it would be fair to have the non-null assertion do a runtime check, and if you want the non-null assertion with no runtime code, just use a type cast.
- z3t4 5y agoI add a bunch of tests at the top of all JS function - To make sure the parameters are correct. There is no good reason to not write these tests. You can throw friendly errors, and bugs will be detected early.
- ragnese 5y agoSo you've written a bunch of bespoke type checkers that run at runtime instead of compile-time... Shouldn't we be able to just have actual static typing instead?
- z3t4 5y agoI also use automatic tests, and most of the time it's the tests inside the functions that detect the error - because the tests runs the code. It's much more simple then trying to prove correctness before the program haven't even run once.