3 ms·
I was always a big fan of Optionals, but having learned Kotlin this year, I was pleasantly surprised at how much non-nullable types seem to remove the need for
by dlbucci 6y ago
I was always a big fan of Optionals, but having learned Kotlin this year, I was pleasantly surprised at how much non-nullable types seem to remove the need for them. And non-nullable can be just as ergonomic as Optionals with the `?:` operator (or `??` in TypeScript). My only issue when working with `strictNullChecks` in TS is that `null` and `undefined` both exist (thanks JS...). I also wish TS adopted a `Type?` syntax like Kotlin that would signify `Type | null | undefined` and could be used anywhere, not just in function parameters and object types (like TS's current `key?: value` syntax).
- srcreigh 6y agoThe tsdef library has a Nilable<T> type that means T | undefined | null. It's not so bad to type with a snippet like ?<tab> => Nilable<|>.
- shhsshs 6y agoThat snippet is a great idea, thanks!
- slewis 6y agoI recommend just treating undefined and null as equivalent (since you can't control which one or ones third-party libraries will use). Everywhere you need to check for them do `!= null` or `== null` which is an idiomatic way to check for either.