This repository was archived by the owner on Nov 3, 2021. It is now read-only.
Repository navigation
This repository was archived by the owner on Nov 3, 2021. It is now read-only.
wasm null should be mapped to JS undefined, not JS null #9
Description
As in any interlanguage mapping, no mapping is perfect but some are more useful than others.
NOTE: It may already be too late to make this change, even if we agree it would have been a good idea.
Wasm null is used for the uninitialized value on of values of nullable types. For nullable types, null will be the unique platform supported value to indicate that the expected value is absent. This corresponds most closely to the JS undefined rather than the JS null. For the ES specification itself, undefined is consistently treated as the indicator of absence:
var x; // x === undefined
let y; // y === undefined
function foo(x) { console.log(x); }
foo(); // unbound parameters bound to undefined
foo(); // non-return returns undefined
({}).z; // absent properties read as undefined
function bar(x = 3) { return x; }
bar(); // 3. unbound parameters use default value
bar(undefined); // 3. parameters bound to undefined act as if unbound
bar(null); // null. null does not emulate unbound
(new Map()).get("x"); // undefined indicates absenceReacted by ExE Boss
Activity
sjrd commentedon Apr 10, 2018
I disagree. My experience as author/designer of Scala.js is that Scala's
nullmaps perfectly well to JavaScript'snull. And that, despite the fact that uninitialized fields of reference types are initialized withnull(as per the JVM behavior).The perfect mapping we found for
undefinedis actuallyunit(written()in Scala). This may seem weird, but is easily explained when you consider "void" functions: in JavaScript, a function without explicitreturn(or withreturn;without expression) returnsundefined; in Scala, a function that does not return any value returns()of typeUnit.The key words here are for nullable types. But wasm also has non-nullable types, for example ints, and those are initialized with
0/false/etc.. Obviously wasm's0cannot map toundefinedin JS. Now, an "undefined int variable" in JS would also be initialized toundefined(because, hey, no types). So the mapping of uninitialized would be inconsistent between nullable types (map toundefined) and non-nullable types (map to0,false, etc.). For that reason, I do not think the "this corresponds closely to the JSundefined" is actually accurate. Or at least, if it did correspond so closely, then so should0, and we know that's nonsense.bnjbvr commentedon Apr 11, 2018
It might also be a source of confusion, because
undefinedthen would be the symptom of two different causes: either a variable was indeed never defined, or it was a null reference that flew out of wasm. This would probably make debugging harder.lars-t-hansen commentedon Nov 15, 2019
@rossberg, can you tag this as [js-api] so that it's plain that it doesn't block the core proposal? Thanks.
rossberg commentedon Nov 15, 2019
Done. I also take the liberty to close this, since it is incompatible with the existing table API.