TC39 Editors
2026-05-01
plaintext logs
prev next
source on github
15:26
<Richard Gibson>

what is the process for changing Editorial Conventions? https://github.com/tc39/ecma262/pull/3832#discussion_r3172092825 highlights some gaps, specifically about how to compare an [extended] mathematical value or bigint against multiple options (which I think should be If _x_ = $a or _x_ = $b when there are two options, and presumably If _x_ = $a or _x_ = $b or _x_ = … when there are more). So I think I'd like the first few bullets of that section to look like

  • when comparing an alias against a single value or collection of options, the alias should be on the left
  • when comparing an alias for equality or inequality against a single value, the preferred form depends upon the type of that value:
  • _x_ = … or _x_ ≠ … for an extended mathematical value or bigint
  • SameValue(_x_, …) for an object, non-well-known symbol, or arbitrary language value
  • _x_ is … or _x_ is not … for anything else (boolean, number, string, well-known symbol, null, undefined, spec enum, etc.)
  • when comparing an alias for equality or inequality against multiple options, preserve explicit pairwise =/≠/SameValue (_x_ = _option1_ or _x_ = _option2_ or _x_ = …) but consolidate is/is not using either/neither for a pair of options (_x_ is neither _option1_ or _option2_) and one of for more than that (_x_ is not of of _option1_, _option2_, or _option3_)
  • an alias can also be compared against a number, bigint, or extended mathematical value using <, ≤, >, or ≥

we should talk about migrating Editorial Conventions into the spec repository itself, but in the meantime I'd just like to clarify the above guidance but don't want to impose excessive churn by just unilaterally editing the GitHub wiki page

15:37
<Richard Gibson>

what is the process for changing Editorial Conventions? https://github.com/tc39/ecma262/pull/3832#discussion_r3172092825 highlights some gaps, specifically about how to compare an [extended] mathematical value or bigint against multiple options (which I think should be If _x_ = $a or _x_ = $b when there are two options, and presumably If _x_ = $a or _x_ = $b or _x_ = … when there are more). So I think I'd like the first few bullets of that section to look like

  • when comparing an alias against a single value or multiple options, the alias should be on the left
  • when comparing an alias for equality or inequality against a single value, the preferred form depends upon the type of that value:
    • _x_ = … or _x_ ≠ … for an extended mathematical value or bigint
    • SameValue(_x_, …) for an object, non-well-known symbol, or arbitrary language value
    • _x_ is … or _x_ is not … for anything else (boolean, number, string, well-known symbol, null, undefined, spec enum, etc.)
  • when comparing an alias for equality or inequality against multiple options, preserve explicit pairwise =/≠/SameValue (_x_ = _option1_ or _x_ = _option2_ or _x_ = …) but consolidate is/is not using either…or/neither…nor for a pair of options (_x_ is neither _option1_ nor _option2_) and one of for more than that (_x_ is not of of _option1_, _option2_, or _option3_)
  • an alias can also be compared against a number, bigint, or extended mathematical value using <, ≤, >, or ≥

we should talk about migrating Editorial Conventions into the spec repository itself, but in the meantime I'd just like to clarify the above guidance but don't want to impose excessive churn by just unilaterally editing the GitHub wiki page

16:01
<Michael Ficarra>
we usually just get agreement in an editor call and then make the change
16:03
<Richard Gibson>
then I guess I should open an issue on the repository so there's something to reference and comment on, right?
16:30
<jmdyck>
What do you mean by "arbitrary language value"?
16:50
<Richard Gibson>
good question. It's any ECMAScript language value that could possibly be an object or non-well-known symbol. More formally, this convention seems to call for use of SameValue whenever the intersection of the set of all possible ECMAScript language values for that operand and the set of all ECMAScript language values compared by identity contains at least one value that is not a well-known symbol (and as an aside, I'd love to remove the well-known symbol exception, which isn't even used in the spec AFAICT—in which case the resulting guidance would be something like "SameValue(_x_, …) for an ECMAScript language value with specification identity or an alias that might be such a value during evaluation")
19:08
<jmdyck>
Talking about "the set of all values for that operand" is a step in a good direction. The first 4 rules under 'Comparisons' assume that we're comparing two values of the same type. But when we're choosing what comparator to write, we don't (in general) have values, we have 'expressions' (in the meta-language), each of which might represent values of several types.