00:14
<littledan>
Also, this should come with some kind of Web IDL story I think.
Yes, I agree with this; maybe we should open a parallel bug in WebIDL to discuss. I think on both ends, the annoying thing is, what do we do with the new world and the old world coexisting, if we try to move in this direction? Should we continue the cautious way that we've been doing with Temporal, or do something more drastic as the title implies?
01:18
<Domenic>

In most cases on the web platform / Web IDL undefined is treated the same as missing. There are two exceptions that I know of, neither of which I'm very happy about:

01:19
<Domenic>
It looks like both of those might be solved by a normalization step that removes trailing undefineds passed by JS, before they hit the Web IDL layer.
01:20
<Domenic>
Although a more principled approach might be padding out missing trailing arguments with undefineds, so there's never a "missing" argument.
01:21
<Domenic>
Anyway, I'm very in favor of unifying undefined and missing wherever possible, in the web and JS. (I'm still pretty sad that JS decided to explicitly differentiate them for error.cause.) Most languages have one level of missing thing (null). It seems fine if JS ends up with two levels: undefined/missing, and null. Making it three-layer (missing, undefined, null) is very unnecessary.
01:24
<Domenic>
Whether the missing/undefined value is treated as an error, or coerced, is a separate question, I guess.
01:32
<bakkot>
In cases where it is clearly the wrong type (for a required argument) I am hoping to move us towards being an error. I really don't see much advantage to it being coerced.
01:32
<bakkot>
document.createElement(object.someMissingProperty) giving you <undefined></undefined> is not doing anyone any good.
01:34
<bakkot>
Also I just remembered I have an issue from a couple months ago about this: https://github.com/w3ctag/design-principles/issues/437 though at the time I hadn't realized that my suggestion actually went against webIDL's current conventions
11:58
<littledan>
Although a more principled approach might be padding out missing trailing arguments with undefineds, so there's never a "missing" argument.
Honestly I am not sure WebIDL should weaken this particular thing (well, definitely not without reducing the weak typing around undefined). This sounds like it would reduce error checking in practical ways.
11:59
<littledan>
Anyway, I'm very in favor of unifying undefined and missing wherever possible, in the web and JS. (I'm still pretty sad that JS decided to explicitly differentiate them for error.cause.) Most languages have one level of missing thing (null). It seems fine if JS ends up with two levels: undefined/missing, and null. Making it three-layer (missing, undefined, null) is very unnecessary.
I think the WebIDL unification aspect was missing from our discussion on Error.cause. Let’s see if we can make that happen in the future. Not everyone in TC39 can be a WebIDL expert…