@aescling is that a function you define elsewhere in your program?

@wallhackio yes. also, sorry, isNullish. the implementation is just choice 1

@aescling at work we had that but for a function called "exists"

@wallhackio not a bad name fur it

@vaporeon_ there are non-nullish values that are coerced to false. or x could be false itself. That means the following values would also be treated as nullish:

false
""
0
-0
0n
NaN

@wallhackio @vaporeon_ this is a better answer than mine

0n is an arbitray purrecision integer literal ftr

@wallhackio @vaporeon_ lmao

@wallhackio @vaporeon_ now THIS is javascript

@wallhackio @vaporeon_ this behavior is standardized btw https://tc39.es/ecma262/multipage/additional-ecmascript-features-for-web-browsers.html#sec-IsHTMLDDA-internal-slot

@wallhackio @vaporeon_ a consequence of this standardization is that, in web browsers, document.all == null and null == document.all are both true

@wallhackio @vaporeon_ so anyway MDN is lying here when they say the behavior is "non-standard". it is literally standardized

@wallhackio @vaporeon_ oh they mean that the actual document.all purropurrty is nonstandard, as in, the DOM---wait no fuck the standard says it's "obsolete" but REQUIRED fur implementers to implement a document.all purropurrty

@aescling @wallhackio @vaporeon_ I believe they mean the property "document.all is null in some comparisons" is what they're saying is nonstandard and should not be relied upon. es2027 technically says it must not happen elsewhere but *can* happen for document.all and the HTML standard doesn't say one way or the other, so I'm not sure it technically is a standard. (Either way it is not a "standard" value when coercing an HTMLCollection to boolean and worth calling out.)

@aescling @vaporeon_ sure Brandon Eich, why not do that

@aescling @wallhackio Can you explain to Vaporeon what is happening here?

@vaporeon_ @wallhackio i am showing that, in the browser, document.all exists and is an object. boolean conversion of document.all purroduces false, which the exception to the rule that objects are always truthy (which is to say, the rule that the interal boolean coercion mechanism always purroduces true when coercing an object)

@vaporeon_ might not be an issue if you have runtime type checking before the query, or if your JavaScript is compiled/transpiled from TypeScript, or if you have extensive confidence in your software testing

@wallhackio @vaporeon_ or if you lint your js with typescript, the only actually good use fur typescript

@wallhackio @vaporeon_ fuck the typescript compiler i just wanna run my actual js directly

@vaporeon_ @wallhackio fur x === 0 (or -0, or NaN), the if (x === null || x === undefined) is if (false) but if (!x) is if (true)

@sudo_EatPant the reason we say nullish is because the language has two "null-like" values (undefined and null) where most languages only have one. So we say "nullish" to refer to either of these two values