4 ms·
I don't know about C# and Swift, but Kotlin, Python, and Typescript are only null-safe-ish; there is always a relatively easy path to smuggling a null value int
by mbStavola 5y ago
I don't know about C# and Swift, but Kotlin, Python, and Typescript are only null-safe-ish; there is always a relatively easy path to smuggling a null value into your program regardless of the guarantees of the types you use.
This isn't to say it's useless, just that it's not as useful as it _could_ be. I've seen codebases in all three languages where there have been real production issues due to null values, even though the type decls say otherwise. Kotlin probably does the best job here but using any JVM library introduces potential (K)NPEs.
- unscaled 5y agoThis situation is unfortunately quite hard to avoid in the languages above since they either added null safety (or indeed any kind of type-checking) at a later stage (C# and Python) or they need to maintain compatibility with a language or platform that is not null-safe (Kotlin with Java, Swift with Objective C, TypeScript with JavaScript). Languages like Rust, Haskell or ML do not have this issue since they do not need to support such a legacy layer.
- pjmlp 5y agoKind of true, there is still the possibility to smuggle null values via unsafe, or FFI, but then the fault is on whoever certified the code as safe.
- unscaled 5y agoI was hesitating whether to mention unsafe code blocks or FFI, but the no language that gets thing done can avoid abuse of its escape hatches. Even Haskell has to deal with nulls when doing FFI.
- wildbook 5y agoAs much as I like C#, your points apply to it too.
- skohan 5y agoHow can you get an unchecked nil into a swift program without the unsafe API?
- bobbylarrybobby 5y agoImplicitly unwrapped optionals
- skohan 5y agoBut this is exactly equivalent to calling `.unwrap()` in rust, no?
- mtelgon 5y agocan you give an example of where typescript fails to protect you against nulls in your own code? (apart from the use of any
- brundolf 5y agoYou can turn off strictNullChecks, and there's also noUncheckedIndexAccess which unfortunately isn't enabled by default even in strict mode. You can also introduce flaws via @ts-ignore, casting, etc. Still, typescript equips you to catch these errors, even if you can technically circumvent it. In practice it can be nearly bullet-proof if you follow good practices.
- appletrotter 5y agoAbusable things: - ! - as x - @ts-ignore
- mbStavola 5y agoAside from explicitly turning off null safety and tricky use of casting, an easy example is interfacing with JS. If you're using either a library that wasn't written in pure TS (maybe JS or JS with .d.ts) or interacting with some unconverted JS from your own codebase, you can easily pass a null through entirely by accident. The problem really stems from the JS end of things, but 9 times out of 10 you're going to be touching JS at _some_ level when using TS so I think it's fair to point out this gap.
- brundolf 5y agoThere's still a huge difference between "you can smuggle a null value in" and "the language can't statically reason about null values at all" You can override TypeScript's checks for anything, not just nulls, and yet people still get tons of benefit from it. Same goes with many of Rust's safety checks in unsafe { } blocks. Additionally, languages like C# and typescript have to be a little more flexible because they added this feature after the fact. Go had plenty of opportunity to do it up front and not require any compromises, and it chose not to.