00:02
<jmdyck>
Editorial-Conventions 'Comparisons' used to have an "(except in asserts)", then 3844 took it out. Was that intentional? (Asking before I change my code.)
00:53
<Michael Ficarra>
No, we generally don't apply the same editorial conventions to asserts, including comparisons. We should add the exception back.
00:56
<Richard Gibson>
we should first check if there are any cases where it matters. But I'd personally be fine with e.g. Assert: _x_ = 0, and suspect we already have steps like that
01:03
<jmdyck>
Why not apply the same editorial conventions to asserts?
01:06
<Michael Ficarra>
Sometimes things like "When x is y, some invariant holds" read better than "When x = y, ...", even though the latter would be mandated if our conventions apply.
01:07
<Michael Ficarra>
or god forbid SameValue
04:55
<Richard Gibson>

so it turns out there's a couple handfuls of assertions that would be in scope for this, but honestly most of them read just fine to me with =/≠. Here are some examples that would change:

  • Number.prototype.{toExponential,toFixed}: If _fractionDigits_ is *undefined*, then _fractionCount_ is 0.If _fractionDigits_ is *undefined*, then _fractionCount_ = 0.
  • {Array,%TypedArray%}.prototype.{includes,indexOf}: If _fromIndex_ is *undefined*, then {_startIndex_,_n_} is 0.If _fromIndex_ is *undefined*, then {_startIndex_,_n_} = 0.
  • DecodeFinalBase64Chunk: _chunkLength_ is 3_chunkLength_ = 3
  • The Abstract Closure Specification Type: _value_ is 42_value_ = 42
  • CreateJSONParseRecord: _valueLength_ is _length__valueLength_ = _length_

In fact, the only two cases that I think would be made worse by such a switch are in Decode and RegExp.escape: The length of {_octets_,_hex_} is {_n_,2}The length of {_octets_,_hex_} = {_n_,2}. I'd be willing to narrowly scope an exception for those (something like "the length of … is …"), or alternatively just refactor them away as e.g. _octets_ has exactly _n_ elements/_hexLength_ = 2.