wasm null should be mapped to JS undefined, not JS null

[erights]

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 absence

[sjrd]

I disagree. My experience as author/designer of Scala.js is that Scala's null maps perfectly well to JavaScript's null. And that, despite the fact that uninitialized fields of reference types are initialized with null (as per the JVM behavior).

The perfect mapping we found for undefined is actually unit (written () in Scala). This may seem weird, but is easily explained when you consider "void" functions: in JavaScript, a function without explicit return (or with return; without expression) returns undefined; in Scala, a function that does not return any value returns () of type Unit.

For nullable types, null will be the unique platform supported value to indicate that the expected value is absent.

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's 0 cannot map to undefined in JS. Now, an "undefined int variable" in JS would also be initialized to undefined (because, hey, no types). So the mapping of uninitialized would be inconsistent between nullable types (map to undefined) and non-nullable types (map to 0, false, etc.). For that reason, I do not think the "this corresponds closely to the JS undefined" is actually accurate. Or at least, if it did correspond so closely, then so should 0, and we know that's nonsense.

[bnjbvr]

It might also be a source of confusion, because undefined then 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]

@rossberg, can you tag this as [js-api] so that it's plain that it doesn't block the core proposal? Thanks.

[rossberg]

Done. I also take the liberty to close this, since it is incompatible with the existing table API.