| 06:37 | <sffc> | In JS/TS, is it better to return null or undefined for a Rust API that returns Option? Trying to decide the default behavior in ICU4X. https://github.com/rust-diplomat/diplomat/pull/435 |
| 07:05 | <ljharb> | sadly we don't have an Option type (alternatively, a sync Promise), and there's no ecosystem consensus on that kind of thing. some people only use one or the other and hate the one they don't use, some people don't care. i don't have a hard rule for myself either, it's more of a "i usually know which one it should be when i see it" |
| 07:06 | <ljharb> | if it's representing an options object, then i'd say undefined, because then that'll trigger arg defaulting if it's passed elsewhere |
| 17:21 | <bakkot> | sffc: personally I would use null if I were doing this without consideration of precedent, but the precedent here is firmly set by wasm-bindgen / wasm-pack, and it uses undefined |
| 17:23 | <bakkot> | https://github.com/rustwasm/wasm-bindgen/pull/3245 contains a recent discussion of that decision |
| 17:24 | <bakkot> | relevantly to you:
|
| 19:06 | <TabAtkins> | I fairly strongly feel that using undefined works better, because it triggers argument defaulting. JS having two nulls has always been weird. |
| 21:52 | <littledan> | This argument cuts both ways—you can recover the defaulting with ?? ! |
| 23:30 | <ljharb> | you'd have to do ?? undefined tho, if you wanted to then trigger the defaulting somewhere else, which is weird and unergonomic and uncommon to know you need to do it |
| 23:53 | <TabAtkins> | In general, JS's precedent is for undefined anyway - see Map.prototype.get(). (DOM goes the opposite way in precedent, due to its unfortunate early flirtation with Java, tho.) |