2026-02-09
[14:18:45.0611] <Michael Ficarra>
@gibson042:matrix.org reminder to update https://github.com/tc39/ecma262/pull/3714 so we can hopefully land it in time for the 2026 spec cut


2026-02-10
[14:42:32.0221] <Michael Ficarra>
next week's editor call is on Presidents' Day (US holiday), should we cancel? @shuyuguo:matrix.org


2026-02-16
[06:46:09.0625] <jmdyck>
TC39 events calendar still says editor call today.

[13:56:58.0134] <jmdyck>
lack of response suggests lack of meeting


2026-02-19
[15:57:20.0284] <bakkot>
Michael Ficarra: finally looking at https://github.com/tc39/ecma262/pull/3733, some of the changes from the last commit https://github.com/tc39/ecma262/pull/3733/changes/9102cfb4622fb5852cc664da031c06d2ce08a52f seem worse

[15:57:42.0877] <bakkot>
like:

          1. If _n_ ≥ 0, then
            1. Let _k_ be min(_n_, _len_ - 1).
          1. Else,
            1. Let _k_ be _len_ + _n_.

is more readable to me than

          1. If _n_ ≥ 0, let _k_ be min(_n_, _len_ - 1); else let _k_ be _len_ + _n_.

[15:57:53.0112] <bakkot>
just in terms of how much is going on within a single line

[15:58:03.0497] <bakkot>
this is my only complaint though

[15:58:29.0798] <bakkot>
maybe we can back some of those out and then land? unless you think it's better on one line


2026-02-20
[21:39:19.0563] <Michael Ficarra>
I have no preference between the two, but if you do, you should try to describe what it is about it that makes you prefer the former so that others can try to maintain consistency

[21:42:52.0255] <bakkot>
there's just too much going on in one line is all

[21:47:19.0539] <bakkot>
if you want a rule to write down, something like

> don't use the single-line "if ... ; else ..." form when any one of the test, consequent, or alternate is complex

 where "complex" is deliberately handwavy

[07:50:04.0242] <Michael Ficarra>
we have "if an early-exiting if/else has just two branches (i.e. not an if-else cascade like in some Math functions), and the two branches are substantially similar and short, prefer a single step", which we could generalise by removing "early-exiting"

[07:51:15.0111] <Michael Ficarra>
anyway, feel free to push up a commit with whatever adjustments you prefer

[08:37:16.0609] <bakkot>
I don't actually prefer a single step in those cases, necessarily, rather it's that I prefer _not_ a single step in the cases where it is _not_ similar and short

[08:38:22.0750] <Michael Ficarra>
so iff?


2026-02-23
[12:21:02.0216] <shu>
i'm out sick today

[15:25:21.0710] <jmdyck>
E.g., if you look at https://tc39.es/ecma262/#sec-get-regexp.prototype.dotAll, the section title "get RegExp.prototype.dotAll" suggests that the section is only about the get accessor function. But the preamble tells you that the set accessor function is *undefined*, so in fact the section is about both accessor functions, i.e. the whole accessor property.


2026-02-24
[20:13:50.0356] <bakkot>
reviewed the `using` declarations PR for editorial details (not really correctness of the grammar/etc). had one comment I'd like other opinions on: https://github.com/tc39/ecma262/pull/3000#discussion_r2844075496


2026-02-25
[15:49:13.0004] <bakkot>
ok actually I would just revert the last commit outright, it's just using a "180-character threshold" which is really not adequate to the task

[15:49:36.0487] <bakkot>
I am not going to write down a more precise heuristic right now, and you wanted to get it landed, so just reverting that and calling it good is the way to go

[15:49:54.0271] <bakkot>
I'll push that up and approve and you can stamp it if you want


2026-02-28
[23:59:03.0309] <ljharb>
would be great to get yalls signoff on https://github.com/tc39/proposal-error-stack-accessor/issues/9