| 07:47 | <yulia> | sure i will look today |
| 09:04 | <ryzokuken> | matrix spaces seem to be getting more stable. should we assign a stable alias to the TC39 space and start publicizing the link? |
| 10:10 | <yulia> | bakkot: i read through everything, I think it looks good |
| 10:11 | <yulia> | I have one question: is there a guidance I can follow on return values? https://github.com/tc39/ecma262/pull/2408/commits/b3e00d294a4fb150197bad80f236815a3de5608c |
| 10:25 | <yulia> | this is also adjusted according to anba's comments https://github.com/tc39/ecma262/pull/2267 |
| 16:25 | <bakkot> | yulia: on returns, the guidance is basically, 1) if the return value isn't going to be consumed, use Return. rather than Return *undefined*, and conversely, and 2) don't bother with Return. as the final step in an AO (unless it would otherwise be empty). |
| 16:25 | <bakkot> | we're not 100% consistent with this right now, but we're close, and I'll fix it up in https://github.com/tc39/ecma262/pull/2429 and https://github.com/tc39/ecma262/pull/2397 once TLA is in |
| 17:36 | <shu> | bakkot: thanks, and yes, that is dumb |
| 19:03 | <Domenic> | Thoughts on whether web APIs should use JS SyntaxError for parsing problems? (Specific API is https://github.com/WICG/urlpattern/.) I see the ES spec uses it for BigInt and JSON.parse, in addition to actual syntax errors. |
| 19:57 | <bakkot> | SyntaxError seems like a reasonable choice to me |
| 19:58 | <bakkot> | JS also uses it for RegExp, which seems like the nearest cousin here |
| 20:08 | <bakkot> | as a bonus, it makes it marginally less awkward to move it into the JS spec if there is ever reason to do so |
| 20:13 | <Domenic> | Sigh |
| 20:19 | <bakkot> | I am mostly thinking of that in the context of moving structured clone, which it sounded like you were interested in doing |
| 20:19 | <bakkot> | and which will be marginally awkward because of the error type differences |
| 20:19 | <bakkot> | only very marginally, though |