| 00:35 | <Michael Ficarra> | @bakkot explain this: https://github.com/tc39/ecmarkup/blob/main/src/Spec.ts#L1878-L1887 |
| 00:36 | <bakkot> | lol |
| 00:36 | <bakkot> | I mean, that one is necessary because ecmarkup outputs utf8 |
| 00:37 | <bakkot> | significantly predates me https://github.com/tc39/ecmarkup/commit/ce5fcdd77cda052fdadc93b0f6bf12f69ecf2f98 |
| 17:28 | <ljharb> | before i merge the pending things, could perhaps https://github.com/tc39/ecma262/pull/3480 land so i don't have to manually check the IPR pre-merge anymore? |
| 17:30 | <Michael Ficarra> | I'm not interested in reviewing it, so if @bakkot says it's good, it's fine by me |
| 17:30 | <bakkot> | yeah ship it |
| 17:36 | <Michael Ficarra> | @bakkot wanna stamp https://github.com/tc39/ecma262/pull/3487 if you approve of that plan? |
| 17:55 | <bakkot> | wfm |
| 18:11 | <bakkot> | ljharb: https://github.com/tc39/ecma262/pull/2924 should land as one commit |
| 18:11 | <ljharb> | ah ok, will fix |
| 18:11 | <bakkot> | as is the second one is basically reverting the first; no reason to have both |
| 19:19 | <bakkot> | shu: https://github.com/tc39/ecma262/issues/3117 we can just pull the 1. Let type be TypedArrayElementType(typedArray). into the abstract closure, yeah? that way it won't happen until after the validation. and it's pure so that's allowed even inside of a read-modify-write modification function |
| 19:20 | <bakkot> | alternative is that we do the validation eagerly there and then allow it to be re-done in the AtomicReadModifyWrite call |
| 19:20 | <bakkot> | I guess I'm fine with either |
| 19:52 | <shu> | bakkot: yeah i'd just put it into the AC |
| 19:53 | <shu> | both the type and the little endian thing don't need to be closed over, actually |
| 19:56 | <bakkot> | depends a little on what you are allowed to do inside of a "mathematical function", which the read-modify-write functions are supposed to be |
| 19:56 | <bakkot> | but I'm fine with it |
| 19:58 | <shu> | spec-wise the requirements are: They perform all their algorithm steps atomically. Their individual algorithm steps are not observable. |
| 19:59 | <shu> | both getting the type and getting the endianess satisfy both counts. implementations should understand the as-if nature that getting the type can be lifted out |
| 19:59 | <shu> | (and since obviously no RMW operations are implemented like this with a higher order function) |