`NaN`/`undefined`/`Infinity` should be matched as bindings rather than static values

[gibson042]

(originally posted by @gibson042 in https://github.com/tc39/proposal-pattern-matching/pull/293#discussion_r1311820104)

function pathological(x, undefined, NaN, Infinity) {
  return match (x) {
    when undefined: "undefined";
    when NaN: "NaN";
    when Infinity: "Infinity";
  }
}

Such bizarre bindings are honored elsewhere in the language (e.g., (NaN => [][NaN])("length") evaluates to 0 rather than undefined) and I believe discouraging the pattern via linters etc. is better than trumping explicit developer intent in match contexts where they are overridden.

[ljharb]

Can you provide concrete examples of when this is actually intended by a developer? I can't say i've ever seen any (except that I've used undefined specifically to ensure it's the literal undefined)

[tabatkins]

They are, now, matched like that per the README (they're just handled by the Variable Matcher section), but I'm not sure exactly what the spec PR currently says. I don't have a strong opinion either way.

[ljharb]

I think that their ability to be bindings is a flaw in the language, and unless there's compelling evidence presented that developers ever actually want this behavior, this is an elegant opportunity to avoid furthering the mistake.

[gibson042]

I strongly disagree that "avoid furthering the mistake [in just this one construct]" would be an improvement: https://github.com/tc39/proposal-pattern-matching/pull/293#discussion_r1313511067

I'm just very sensitive to these kinds of epicycles—it's better IMO for the language to be consistently weird in having shadowable undefined/NaN/Infinity than for them to be shadowable in some contexts but not in others.