| 02:11 | <ljharb> | p sure i can understand the logic that led to that behavior, but i'd def argue it should either unconditionally coerce or not coerce at all |
| 02:34 | <bakkot> | yeah, it violates the general principle of validating/coercing the receiver and arguments up front before doing any of the logic |
| 02:34 | <bakkot> | which we should write down... |
| 16:26 | <Aki> | am I misunderstanding how ecmarkup biblios work, or do IDs need to be unique across all locations/sources, even if you're including several biblios? |
| 16:26 | <Aki> | (the docs are a little out of date) |
| 16:46 | <peetk> | hello! JSON.parseImmutable has a new name and spec: https://github.com/tc39/proposal-json-parseimmutable we are going with the options-bag idea discussed at the last plenary. since it was already widely discussed then, we're thinking of bringing it for Stage 2.7 at the September/October plenary. can anyone volunteer as stage 2.7 spec reviewers? |
| 16:51 | <Chris de Almeida> | ljharb and rkirsling were the original stage 2 reviewers. that was back in 2022, but they are technically still on the hook 😁 |
| 19:02 | <ljharb> | sure, i'll rereview |
| 21:36 | <eemeli> | Given how much I pushed for the now-proposed API shape, it's perhaps only fair that I also volunteer to review, if you need another. However, I won't be able to participate in the September call, so feedback will be on GitHub only if you're asking for stage advancement then. |