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 "= is tighter than yield" is false; they're both produced by AssignmentExpression
Ah, looking at the actual spec, you’re right. I was going off the table in https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Operators/Operator_Precedence#table …which someone ought to edit and fix, I guess.
06:30
<bakkot>
that table also lists ?? and || as different precedence, which is also wrong
06:58
<jschoi>
that table also lists ?? and || as different precedence, which is also wrong
Also true. I left this; they might fix it later. https://github.com/mdn/content/issues/5365
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)
That is so awesome!
12:04
<sideshowbarker>
That is so awesome!
You can thank jgraham for having taken the initiative on setting it up
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?
Yeah, that’d be nice to have
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:

.mx_EventTile {
    margin-top: 10px;
}
.mx_IRCLayout .mx_EventTile > .mx_SenderProfile {
    margin-right: 8px;
}
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>

Maybe that's what I'm not understanding: What's AssertionError?

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