4 ms·
Yeah, agreed. Option often appears in my typescript code in the form of possibly undefined variables. I unpack the Option by using a condition if I want to hand
by Waterluvian 4y ago
Yeah, agreed. Option often appears in my typescript code in the form of possibly undefined variables. I unpack the Option by using a condition if I want to handle it or assert() if I just want the application to panic.
I love how TypeScript forces this. You need to narrow the “undefined” type away before you can use the object in any way. Ruling out undefined and narrowing the type is the equivalent of checking for Some or None.
- Nullabillity 4y agoIt's not quite the same though. Since TypeScript uses union types, `T | undefined | undefined` is equivalent to `T | undefined` (and might even be `T`, depending on how that is defined!), while `Option<Option<T>>` is always a distinct type from `Option<T>`
- masklinn 4y agoWhich is why TypeScript has T | null | undefined <taps temple>
- Waterluvian 4y agoThere’s no one right answer but this is how I pick, in many cases, when to use null vs undefined.
- eyelidlessness 4y agoAgree (at least for non-personal projects, where I might be more inclined to use Option/Result types). Wherever possible, I use null as an explicit value when a reference is present but not currently assigned a value, and treat undefined as absence of a reference. I try not to even use the undefined keyword if possible (which is sometimes necessary in types, but I can’t remember the last time I used it in runtime code).
- Nullabillity 4y agoThat still doesn't let you represent `Option<Option<Option<T>>>`, requires you to remember the difference between null and undefined, and fails silently if you screw any of it up.