| 00:37 | <bakkot> | I have no preference; whichever you'd prefer / is easier is fine by me |
| 00:59 | <ljharb> | doesn't make a difference; i'll keep them separate |
| 00:59 | <ljharb> | bakkot: altho actually there's a merge conflict, so if you could rebase it first that'd be great :-) |
| 01:41 | <bakkot> | ljharb: done |
| 01:41 | <ljharb> | thanks |
| 16:11 | <Michael Ficarra> | handy link for finding PRs awaiting your review: https://github.com/tc39/ecma262/pulls?q=is%3Apr+is%3Aopen+sort%3Aupdated-desc+-reviewed-by%3A%40me+review%3Aapproved+-label%3A%22editor+call%22+draft%3Afalse+-label%3A%22ready+to+merge%22 |
| 16:39 | <Michael Ficarra> | let's use assignment or something for PR review pings and save editor call for stuff we legitimately want to discuss during the call |
| 16:40 | <Michael Ficarra> | right now, I see issues that I would review if not for the editor call label because I assume there's some nuance to be discussed |
| 16:43 | <ljharb> | is assignment going to be noticed more than being in the "reviewers" list? |
| 16:43 | <ljharb> | we might not even need review pings if people reflexively looked at the "awaiting review by you" list: https://github.com/tc39/ecma262/pulls?q=is%3Apr+is%3Aopen+sort%3Aupdated-desc+-label%3A%22editor+call%22+draft%3Afalse+-label%3A%22ready+to+merge%22+review-requested%3A%40me |
| 16:43 | <Michael Ficarra> | I think it sends me a notification whenever I get assigned, so I assume so |
| 16:44 | <ljharb> | it sends you one when you're requested to review as well, but that doesn't seem to get things on people's queue consistently |
| 16:48 | <ljharb> | i'm going to make a meta commit to change "twelfth" to "thirteenth" for #2516; ok to push directly, or would yall prefer a PR? |
| 16:59 | <Michael Ficarra> | I think both should be PRs |
| 17:10 | <ljharb> | sounds good |
| 17:11 | <Michael Ficarra> | on the latter point, I don't think we need to go into so much detail about UTF-8 |
| 17:11 | <ljharb> | https://github.com/tc39/ecma262/pull/2517 |
| 17:11 | <Michael Ficarra> | I added editor call label to discuss dropping most of that comment |
| 17:11 | <Michael Ficarra> | *note |
| 17:11 | <ljharb> | removing the detail seems fine to me, i'm only concerned that like unicode, an external group might have introduced normative changes without us realizing |
| 17:33 | <shu> | name bikeshedding: for the options object AOs in 402 that'll end up being in 262 now with Temporal |
| 17:34 | <shu> | what should we call those? do we just call those "options objects" without qualification? 262's options bags don't behave like that and behave differently from function to function (like Error constructor checking presence of cause with Has) |
| 17:35 | <Michael Ficarra> | shu: link to such an AO? |
| 17:37 | <shu> | https://tc39.es/ecma402/#sec-getoptionsobject and the AOs below it |
| 17:37 | <shu> | Temporal uses them as well |
| 17:40 | <ljharb> | "options object" seems fine, and cause is a special case (but would happen again whenever undefined is a valid value in an options bag) |
| 17:44 | <shu> | what about the options i'm adding with resizable buffers? |
| 17:45 | <shu> | i... guess they could use those, actually? i need to look closer |
| 17:45 | <shu> | anyway i guess the bigger normative question is when this gets pulled in via temporal, are we on board with using this style of options objects by default |
| 17:46 | <bakkot> | what is meant by "this style" |
| 17:51 | <shu> | the one in 402 |
| 18:27 | <bakkot> | meaning, undefined is equivalent to empty object bag w/ null proto, non-object is TypeError? that seems like a reasonable choice |
| 18:32 | <shu> | also no Has checks |
| 18:32 | <shu> | (also reasonable) |
| 18:42 | <bakkot> | yup, seems good |
| 18:42 | <bakkot> | IIRC that's what resizable arraybuffer ended up with? |
| 19:10 | <shu> | i think so |
| 19:27 | <ljharb> | i think Has checks should only ever be the way it's done when undefined is a meaningful option value, which will be very rare |
| 19:43 | <shu> | agreed |