| 00:31 | <SoftwareChris> | https://twitter.com/assortedhackery/status/1397389032519307266 |
| 02:43 | <jschoi> | Is there any particular reason why function * f () { 0 + yield 1; } causes yield to be interpreted as an identifier? |
| 02:44 | <jschoi> | …Oh, right, because + has tighter precedence. |
| 03:02 | <jschoi> | Wait, but then how is it possible that function * f () { x = yield 1; } is valid? = is tighter than yield. |
| 03:04 | <jschoi> | Ah, I see, there’s an AssignmentExpression : YieldExpression production specifically for this case… |
| 04:24 | <bakkot> | jschoi: I think "= is tighter than yield" is false; they're both produced by AssignmentExpression |
| 04:25 | <bakkot> | that is, I would say they have the same precedence, and bind left-to-right |
| 05:18 | <jschoi> | jschoi: I think " |
| 06:30 | <bakkot> | that table also lists ?? and || as different precedence, which is also wrong |
| 06:58 | <jschoi> | that table also lists |
| 11:38 | <sideshowbarker> | PSA: there’s now a #whatwg:matrix.org room on Matrix (thanks all y’all for leading the way and setting a good precedent by having set up here) |
| 12:01 | <ryzokuken> | PSA: there’s now a #whatwg:matrix.org room on Matrix (thanks all y’all for leading the way and setting a good precedent by having set up here) |
| 12:04 | <sideshowbarker> | That is so awesome! |
| 12:14 | <ryzokuken> | sideshowbarker: we had set up a "how to set up a new room" guide earlier but I suppose it's not too discoverable, and just now set up a "new user" guide. Perhaps it would be nice to have a canonical "matrix for standards bodies/committees" guide that we could reference? |
| 12:16 | <sideshowbarker> | sideshowbarker: we had set up a "how to set up a new room" guide earlier but I suppose it's not too discoverable, and just now set up a "new user" guide. Perhaps it would be nice to have a canonical "matrix for standards bodies/committees" guide that we could reference? |
| 12:19 | <ryzokuken> | First things first, I'd move the "setting up a new room" guide to the how-we-work repo we have, and then we can consolidate the documentation with whatever other folks have 😀 |
| 19:42 | <rickbutton> | I'm looking for the bit of static semantics that prevents while (true) function fn() {}, I see various early errors for restrictions on labelled statements as the Statement of a WhileStatement but none for a non-labelled function |
| 19:42 | <rickbutton> | any ideas? |
| 19:45 | <rickbutton> | rubber duck strategy, I think I found it: https://tc39.es/ecma262/#prod-ExpressionStatement |
| 21:02 | <bakkot> | rickbutton: there's no static semantics which prevents it because it's not allowed by the grammar in the first place |
| 21:02 | <bakkot> | function fn() {} is a Declaration, and the RHS of a while is a Statement |
| 21:03 | <bakkot> | there's a special annex-B exception which allows FunctionDeclaration as the RHS of an if: https://tc39.es/ecma262/#prod-annexB-IfStatement |
| 21:03 | <bakkot> | but it's only for if, not while |
| 21:06 | <jmdyck> | function fn() {} could also be a FunctionExpression, which the grammar disallows in a different way, which is I think the way that rickbutton found. |
| 21:36 | <rickbutton> | ah I see, thanks bakkot |
| 21:42 | <sideshowbarker> | ljharb: bakkot I find the "irc style layout" a lot more readable after hacking the CSS to do this: |
| 21:44 | <sideshowbarker> | I use the Stylish browser extension to make it do that |
| 21:45 | <sideshowbarker> | It just adds some more vertical line height between messages, and some more space after the nicks. But without that, it all looks a bit too cramped for my taste at least. |
| 23:16 | <DerekNonGeneric> |
Justin Ridgewell: it is probably best described in my half-baked (unpresented & unofficial) proposal for it https://github.com/DerekNonGeneric/proposal-assertion-error |
| 23:22 | <Justin Ridgewell> | Ohhhhhhh |
| 23:22 | <Justin Ridgewell> | You're talking about things like assert.equal(actual, expected) |
| 23:23 | <Justin Ridgewell> | That's very different than AMP's ExpectedError |
| 23:23 | <Justin Ridgewell> | We're not doing comparisons, "expected" for us is errors that we know will happen in practice and cannot be fixed. |
| 23:23 | <Justin Ridgewell> | They're not programmer errors, essentially, they're environment errors |
| 23:24 | <Justin Ridgewell> | We have ExpectedError so that we can keep track of them in metrics |
| 23:24 | <Justin Ridgewell> | If we see an ExpectedError spiking in graphs, we know something in the environment has changed |
| 23:24 | <DerekNonGeneric> | dang, sounds like that could be a separate proposal then 😅 |
| 23:26 | <DerekNonGeneric> | looking at a bunch of other languages, almost all of them have an AssertionError |
| 23:26 | <DerekNonGeneric> | so, i was under the impression that one would be able to use it for run-time feature detection errors, but it seems like that would be an ExpectedError in reality |
| 23:28 | <Justin Ridgewell> | Yah, that sounds like an ExpectedError |
| 23:31 | <DerekNonGeneric> | cool, good to know -- i am going to see if i find time to polish off the rough edges of that proposal and might ping you later on to have a look if you don't mind |
| 23:32 | <DerekNonGeneric> | there are so many things to consider about it and rn the explainer text is still not up to snuff w/ what i would like it to be |