wasm null should be mapped to JS undefined, not JS null about reference-types

[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.

[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.

[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.