2020-10-02
[13:53:50.0000] <ljharb>
akirose bterlson robpalme MylesBorins: we're using a free product to do our spec build previews in CI on ecma262. they want to mention us in some of their materials. is that fine to let them do? i'd provide a quote/testimonial, and they'd be happy for us to review everything beforehand if that's a concern.

[13:57:33.0000] <ljharb>
currently it's "Another customer, TC39 (the standards body governing ECMAScript, commonly known as JavaScript), switched their workloads to Begin to run the JS spec's build previews. With each new proposed change to the JavaScript standard, a new preview is rendered and published with Begin. [quote here]"

[13:57:40.0000] <MylesBorins>
This sounds like an ECMA question

[13:57:54.0000] <MylesBorins>
ah bergin

[13:57:55.0000] <MylesBorins>
fun

[13:57:57.0000] <ljharb>
Begin yeah

[13:57:58.0000] <MylesBorins>
I like brian

[13:58:04.0000] <MylesBorins>
I'd say email the charis

[13:58:07.0000] <ljharb>
brian and ryan have been really helpful

[13:58:08.0000] <MylesBorins>
and we can forward to ecma

[13:58:08.0000] <ljharb>
ok cool, will do

[13:58:16.0000] <MylesBorins>
just good to have paper trail

[13:58:23.0000] <ljharb>
is there a chair-specific email

[13:58:24.0000] <ljharb>
?

[13:58:52.0000] <MylesBorins>
TC39Chairs <tc39chairs⊙eo>

[13:59:27.0000] <ljharb>
thanks, sent


2020-10-05
[13:20:53.0000] <ljharb>
rickbutton: on the R&T doodle, could you enable "if need be" options?

[13:35:57.0000] <rickbutton>
done ljharb

[13:36:16.0000] <ljharb>
ty

[13:36:55.0000] <rickbutton>
np


2020-10-06
[07:21:24.0000] <littledan>
hey, it'd be great to have your comments on TC39 and MDN https://github.com/tc39/Reflector/issues/324 . I'd like to bring this to a proposal to the Ecma GA on a budget allocation.

[07:21:30.0000] <littledan>
I don't think we should be dissuaded by Istvan saying it's out of scope--the budget is determined by Ecma membership, and he personally has a big conflict of interest, being a consultant paid by Ecma just to help TC39, with a budget similar to what a tech writer would cost.

[07:22:02.0000] <littledan>
if we as a committee express our interest in this, I believe Ecma will be responsive.

[07:23:28.0000] <littledan>
(well, I can't say for sure what Ecma's consulting budgets are, as Ecma still hasn't released the organization budget information that I requested some months ago, but I'll keep trying to find out)


2020-10-07
[10:35:08.0000] <ljharb>
rickbutton: can you add the temporal call to the TC39 calendar?

[10:35:32.0000] <rickbutton>
do you mean r&t? and yes, I just pinged ystartsev about it

[10:35:54.0000] <ljharb>
oops yes r&t

[10:35:57.0000] <ljharb>
cool, thanks

[10:41:20.0000] <rickbutton>
lol, some of those invite emails got blocked because of DMARC settings

[10:41:22.0000] <rickbutton>
damn you, DMARC

[11:12:48.0000] <ljharb>
what's dmarc?

[11:14:13.0000] <rickbutton>
Domain-based Message Authentication, Reporting and Conformance

[11:17:09.0000] <rickbutton>
I don't use GMail for email, but sent this invite with my Google "Workspace" account, the domain for which is no longer configured to allow Google to send emails on it's behalf, so even though Google sent the invites out, Google blocked the invites. lol

[11:20:43.0000] <ljharb>
aha

[11:21:05.0000] <rickbutton>
the Record and Tuple monthly call is on the TC39 calendar, I mentioned this in the issue but if anyone here needs an invite plz reach out

[11:21:16.0000] <rickbutton>
ljharb: did you get a meeting invite to your gmail?

[11:22:46.0000] <ljharb>
nope

[11:23:30.0000] <rickbutton>
kk, think I've fixed the config so I'll resend

[11:25:44.0000] <rickbutton>
didn't get a bounce message that time, so either it worked that time or it's in the void forever ljharb

[11:26:40.0000] <ljharb>
just got it

[11:26:47.0000] <ljharb>
thanks!

[11:26:47.0000] <rickbutton>
fantastic.

[11:37:26.0000] <ljharb>
MylesBorins: robpalme akirose bterlson: btw i haven't gotten a reply yet to my chairs email from last week :-) gentle ping

[12:00:03.0000] <MylesBorins>
ljharb we probably won't get to it until the chair meeting friday tbh

[12:00:12.0000] <MylesBorins>
unless it is a super time sensitive request

[12:00:23.0000] <MylesBorins>
feel free to ping the email thread one more time if it is time sensitive

[12:02:36.0000] <ljharb>
ah ok cool, that's fine

[12:02:43.0000] <ljharb>
just didn't know if it'd even been received

[16:07:51.0000] <ljharb>
Bakkot: should i hold off on 2142? i was about to merge it

[16:08:06.0000] <ljharb>
oh oops, it doesn't have the stamps anyways

[16:08:14.0000] <ljharb>
nvm, definitely not merging that rn


2020-10-10
[23:14:05.0000] <ljharb>
MylesBorins: any update after today's chair meeting?

[02:55:17.0000] <robpalme>
https://www.irccloud.com/pastebin/9Tqt5uVO/


2020-10-12
[07:35:41.0000] <littledan>
Hey, I encourage delegates to express your thoughts on Ecma support for MDN at https://github.com/tc39/Reflector/issues/324 with an emoji react or comment

[07:36:20.0000] <littledan>
Also, if you're interested in Async Context, please fill out this doodle: https://doodle.com/poll/3ukz9dhwu27uxb8b

[12:07:09.0000] <ljharb>
leobalter: re ecma402 - i had patrick fix all the console errors on https://ecma-international.org/ecma-402/7.0/ but it doesn't seem right still. can you take a look and lmk what i should tell patrick?

[12:09:01.0000] <leobalter>
he

[12:09:07.0000] <leobalter>
there is a print error in the page

[12:10:09.0000] <leobalter>
https://usercontent.irccloud-cdn.com/file/RIAbtKZW/Screen%20Shot%202020-10-12%20at%2012.08.49%20PM.png https://usercontent.irccloud-cdn.com/file/z85mJkvW/Screen%20Shot%202020-10-12%20at%2012.09.50%20PM.png

[12:12:45.0000] <ljharb>
ah ty


2020-10-13
[12:28:00.0000] <rwaldron->
littledan can you link to any docs or whatever for Async Context?

[12:28:22.0000] <rwaldron->
(I wonder if this is anything like the ridiculous "async block" idea I had a few years ago)

[13:04:38.0000] <bradleymeck>
rwaldron-: it is basically a standardized form of https://nodejs.org/dist/latest-v14.x/docs/api/async_hooks.html#async_hooks_class_asynclocalstorage

[13:04:57.0000] <bradleymeck>
https://github.com/legendecas/proposal-async-context

[13:05:06.0000] <bradleymeck>
https://docs.google.com/presentation/d/1Ef2JI4ntkWd-M8fDqOGZGGh7CiPD05L39CZRSv1II_0/edit#slide=id.p

[13:22:04.0000] <rwaldron->
bradleymeck rad, thanks


2020-10-14
[05:15:45.0000] <littledan>
rwaldron-: If you're thinking of async do expressions, I'd be really in favor of them. We just need to move forward on do expressions!

[05:16:03.0000] <littledan>
but an async block statement also makes sense to me, as a complement

[06:09:52.0000] <rwaldron->
littledan not Async Do Expressions, but yes the that I was "floating" a few years ago was essentially an "Async Block Statement" (sort of?): `async {   /* this code is executed async */ }`. I stopped pursuing it because `(async () => { })()` can be used to achieve the same outcome.

[06:10:09.0000] <rwaldron->
but yes the idea that*

[06:10:55.0000] <littledan>
Yeah, I think that is a good idea for a complement

[06:11:06.0000] <littledan>
I would be in favor of that addition

[06:11:27.0000] <rwaldron->
I had a practice of marking synchronous code with labelled blocks and wanted to be able to do something similar for async stuff that didn't need to return anything

[06:12:15.0000] <rwaldron->
"I think that is a good idea for a complement [09:11:06]  <+littledan> I would be in favor of that addition" ... Neat!

[06:12:17.0000] <rwaldron->
:D

[06:14:22.0000] <littledan>
One "hard part" is deciding what to do about var declarations, return, break, etc in such a block. I like bakkot's suggestion for do expressions to just ban them all

[06:18:40.0000] <rwaldron->
I would definitely ban var, but it's not a function so there is no return, and not a loop thing so there is no continue. That leaves break, which I think might be useful (unless there is some strong argument that I'm not aware of?)

[06:20:32.0000] <rwaldron->
https://i.gyazo.com/4ecb7eed84e4f6a74d740c82868baaf1.png

[07:38:33.0000] <bradleymeck>
my main concern is swallowed errors

[07:38:57.0000] <bradleymeck>
return/break/etc. are confusing but probably not fatal

[08:09:26.0000] <littledan>
rwaldron-: I guess break could work if it comes before the first await, but sometimes you can't statically tell whether it will be preceded by an await or not

[08:10:05.0000] <littledan>
oh, to break out of the async block? yeah, that case seems fine

[08:10:28.0000] <littledan>
but only that one label could be allowed (and inner labels), not labels that are further out

[08:10:40.0000] <rwaldron->
Yes, just to break out of the async block

[08:11:08.0000] <rwaldron->
I would be +1 to disallowing the label by name

[08:11:26.0000] <littledan>
yeah so it seems like we agree on all these points. IMO we should go for your idea here. Let me know if there's something I can do to help.

[08:11:37.0000] <devsnek>
async blocks seem meh

[08:11:44.0000] <littledan>
devsnek: why?

[08:11:49.0000] <devsnek>
because of all the rules y'all are iterating through here

[08:11:59.0000] <rwaldron->
devsnek isn't wrong

[08:12:01.0000] <devsnek>
recreating functions from first principles lol

[08:12:03.0000] <rwaldron->
¯\_(ツ)_/¯

[08:12:31.0000] <rwaldron->
devsnek see above, that's why I ultimately stopped pursuing this idea.

[08:13:13.0000] <devsnek>
it's interesting but also scary

[08:14:30.0000] <rwaldron->
But maybe there's merit to "something that is definitely not a function, that ensures async execution". Maybe that thing is async do expressions.

[08:15:32.0000] <devsnek>
yeah I like the idea...

[08:16:09.0000] <devsnek>
there are just so many assumptions people need to have that are already implied by function boundaries... it seems like a learning nightmare

[08:41:58.0000] <mathiasbynens>
I'll just leave this here: https://github.com/tc39/ecmarkup/pull/263#issuecomment-708470782

[08:42:10.0000] <mathiasbynens>
whoops, didn't mean to link to any specific comment https://github.com/tc39/ecmarkup/pull/263

[09:17:21.0000] <Bakkot>
mathiasbynens neat, although I am extremely hesitant to rely on chrome-only APIs; has any other browser even started work on this, to your knowledge?

[09:17:45.0000] <ljharb>
rwaldron-: if do expressions exist, then async do expressions seem like an easy/trivial addition on top of them to me

[09:17:59.0000] <rwaldron->
ljharb agreed.

[09:18:25.0000] <mathiasbynens>
Bakkot: it’s not “relying” — browsers that don’t yet implement this modern CSS feature just don’t get the benefit (i.e. they get the same experience they’re getting today)

[09:18:40.0000] <mathiasbynens>
Bakkot: but yeah only Chrome implements this standard, currently

[09:22:29.0000] <Bakkot>
mathiasbynens I don't really care about whether you label this a standard; my concern is whether other browsers are intending to ship it

[09:25:08.0000] <Bakkot>
I am not dead set against chrome-only performance hacks, especially since this is a chrome-only performance issue in the first place - god knows I've shipped enough of those - I'd just be more comfortable if other browsers had said they were working on shipping the feature

[09:25:29.0000] <Bakkot>
(that is, it would no longer feel like a chrome-only hack)

[09:31:58.0000] <mathiasbynens>
Bakkot: Mozilla is on board: https://github.com/mozilla/standards-positions/issues/135#issuecomment-650923098 WebKit: <crickets> https://lists.webkit.org/pipermail/webkit-dev/2020-May/031217.html

[09:32:05.0000] <Bakkot>
hmm

[09:32:08.0000] <Bakkot>
thanks

[09:39:07.0000] <Bakkot>
that certainly does give a much nicer experience in Chrome

[09:40:00.0000] <Bakkot>
will land once the upstream bug (which I also observe) is fixed on chrome stable and you've marked the PR ready to go

[10:26:07.0000] <Bakkot>
mathiasbynens also there was https://github.com/tc39/ecmarkup/pull/261; I'm not sure how these things interact


2020-10-15
[03:09:37.0000] <littledan>
(I think multiple implementations is still a meaningful bar, even if there is support from others--it's the standard we use in TC39, after all)

[03:10:53.0000] <littledan>
devsnek: I disagree that iterating through rules means that the feature is suspect. These all follow by logical consequence, I think

[03:11:25.0000] <littledan>
I don't think this would be a lot of stuff to learn in practice

[11:04:47.0000] <bradleymeck>
i think i asked last time but are we no longer hosting the frameworks outreach calls?

[11:05:55.0000] <ljharb>
bradleymeck: it's happening right now

[11:06:05.0000] <ljharb>
it's on the TC39 calendar

[13:16:55.0000] <ljharb>
Bakkot: on 2132, do you think the commits need to stay separate, or is squashing fine?

[13:22:35.0000] <ljharb>
actually nvm, i can figure that out

[13:39:25.0000] <Bakkot>
rkirsling https://github.com/tc39/ecma262/pull/2164 needs a rebase; want to take care of it, or shall I?

[13:39:38.0000] <Bakkot>
it's probably mostly https://github.com/tc39/ecma262/pull/2007 which conflicts

[13:42:44.0000] <rkirsling>
happy to do so; I'll ask if something's unclear

[13:51:20.0000] <rkirsling>
Bakkot: done


2020-10-16
[06:50:07.0000] <bradleymeck>
do we publicize the calendar? I'm seeing it is publicly available and it has been linked to a couple of times in public but it doesn't seem to have a link on any regular place like https://tc39.es/

[08:04:54.0000] <littledan>
TC39 inclusion call happening now at https://meet.google.com/yyk-tqew-zvf

[08:05:00.0000] <littledan>
bradleymeck: Yeah, I agree we have more to do there

[08:05:24.0000] <bradleymeck>
littledan: I'm more just asking if we can publicize it

[08:05:31.0000] <littledan>
yeah, let's do so

[08:08:21.0000] <littledan>
MylesBorins: davepoole ^

[08:08:42.0000] <MylesBorins>
oh shoot

[08:08:50.0000] <MylesBorins>
was there no calendar event that went out for that?

[08:08:52.0000] <MylesBorins>
gimme 2 minutes

[08:09:04.0000] <mpcsh>
there was, we didn't publicize it beyond the reflector thread

[08:09:12.0000] <mpcsh>
sorry about that

[08:19:59.0000] <MylesBorins>
mpcsh generally I would have expected my email address to have been added to the event if I was included

[08:20:00.0000] <MylesBorins>
I'll be there soon

[08:20:10.0000] <MylesBorins>
but if it's not on my calendar I don't know it exists (and will over book it)

[08:20:27.0000] <MylesBorins>
(that also sounded harsher than intented)

[08:20:33.0000] <mpcsh>
MylesBorins: ahh, understood. that's my bad, first time scheduling an event with a group of delegates

[08:20:45.0000] <MylesBorins>
np, happens :D

[09:08:09.0000] <mpcsh>
related to the above, is there a list of delegates' emails somewhere?

[09:33:36.0000] <mpcsh>
(cc chairs who were on the call - MylesBorins, robpalme ^)

[09:34:08.0000] <MylesBorins>
there is an email alias I can share with you, I don't know how up to date it is though

[11:13:46.0000] <mpcsh>
MylesBorins: I was more looking for a map of delegates to emails so that I don't have to reach out to everyone to find what email they'd like me to add to the event. but I'll just go ahead and do that

[11:13:57.0000] <MylesBorins>
there is an email list

[11:14:13.0000] <MylesBorins>
but not a delegate email map that is readily available faik

[11:14:34.0000] <mpcsh>
got it. we should probably have that, I feel like...

[11:54:49.0000] <TabAtkins>
picked this back up after it had been sitting in my sublime tabs for months; still iterating a bit, but i think the proposal is mature enough to share: https://gist.github.com/tabatkins/5c336285c7f6d7d6522561e97f4d98fb

[11:55:00.0000] <TabAtkins>
take N on pattern-matching

[12:01:09.0000] <ljharb>
TabAtkins: i need to get another call set up for the pattern matching proposal; it’d be great to talk about it there

[12:09:13.0000] <TabAtkins>
Argh, I think our last informal discussion on this happened in #tdz, so it's not logged and I cant' verify i hit all the cases we talked about :(

[12:38:52.0000] <mpcsh>
oh no did I miss a discussion in TDZ? that's unfortunate. regardless yes ljharb I've been meaning to ping you about setting up another call, it would be great to do that soon

[12:49:55.0000] <ljharb>
i'll send out an email in the next week, for the week or two after that

[13:03:59.0000] <ptomato>
mpcsh: may I have an invitation to the following inclusion WG call please?

[13:04:22.0000] <mpcsh>
ptomato: yep! please DM me the email address I should send an invite to

[13:05:18.0000] <ptomato>
let's see if DMing works over this Matrix bridge...


2020-10-22
[11:50:07.0000] <rkirsling>
what is the right way to deal with spam comments

[11:50:35.0000] <ljharb>
rkirsling: in this case it's a spam review, so there's basically nothing that can be done.

[11:50:46.0000] <ljharb>
in general we usually hide them as spam, and then also report them to github

[11:50:48.0000] <rkirsling>
ahh

[11:50:52.0000] <rkirsling>
yeah I reported to GH

[11:51:01.0000] <rkirsling>
but then wasn't sure whether that was the right way

[11:51:17.0000] <rkirsling>
out of curiosity, the review _message_ can't be hidden?

[11:51:18.0000] <ljharb>
if github deletes the user then i think the review disappears too, and if so that's the only way to get rid of a review

[11:51:21.0000] <ljharb>
correct

[11:51:25.0000] <rkirsling>
interesting

[11:51:57.0000] <ljharb>
we could edit the review comment text, but that's a step that's best to avoid unless it's like, blatantly offensive content or something

[11:58:06.0000] <rkirsling>
agreed


2020-10-26
[09:51:06.0000] <bradleymeck>
is there a reason we delegate out to Array#Symbol.iterator by default for classes w/o a constructor? just that it was easier to write the spec?

[10:40:04.0000] <ljharb>
i wouldn't expect the default constructor to differ from "code that does the same thing"

[10:41:09.0000] <ljharb>
also i assume you can't do `super.apply(null, arguments)` or anything, so you have to use `...` on the super call

[10:43:14.0000] <bradleymeck>
you can do things like spread the constructor via a literal generator

[10:43:27.0000] <bradleymeck>
it would act same as syntax but be... more complex looking

[10:43:40.0000] <bradleymeck>
in reality engines wouldn't need to do those things

[10:48:58.0000] <ljharb>
a literal generator?

[10:49:39.0000] <bradleymeck>
super(...(function* () {let i = 0; while (i < args.length) yield args[i++];})())

[10:50:01.0000] <bradleymeck>
though i guess that implicitly relies on the generator prototype being safe

[10:50:04.0000] <ljharb>
wouldn't that be vulnerable to deleting Iterator.prototype[Symbol.iterator]?

[10:50:19.0000] <ljharb>
i don't think array spread can ever be a safe/robust operation

[10:50:33.0000] <ljharb>
i suspect we'd need a way to use `arguments` and `.apply` with `super`

[10:50:35.0000] <bradleymeck>
i'd agree, this is a problem in node's SafeMap impl as well

[10:50:49.0000] <bradleymeck>
rest params are safe

[10:50:53.0000] <ljharb>
doesn't SafeMap have a nonconfigurable prototype property tho?

[10:50:54.0000] <bradleymeck>
no need to use arguments

[10:51:07.0000] <bradleymeck>
ljharb: yea, but the super call in unsafe YOLO

[10:51:07.0000] <ljharb>
right, but the resulting call to `super` isn't

[10:51:09.0000] <ljharb>
right

[10:51:42.0000] <ljharb>
lol you could for-loop over the args in the SafeMap constructor and build a SafeSet, and then spread that into `super` :-p

[10:51:50.0000] <ljharb>
or the same with a "SafeArguments" construct

[10:52:35.0000] <bradleymeck>
i mean safeset also leaks idk if that would fix it

[10:52:48.0000] <bradleymeck>
in general super(...varargs) is just dangerous imo

[10:53:02.0000] <bradleymeck>
until we have a way to properly spread w/o hooks

[10:53:45.0000] <ljharb>
right

[10:53:57.0000] <ljharb>
if we had that, i'd be 1000% in favor of changing the default constructor

[10:54:51.0000] <ljharb>
i wonder if it'd be web compatible to make spreading of an IsArray() *not* delegate to Symbol.iterator? i guess that'd mess with array subclasses tho. but maybe if the constructor is %Array%?

[10:55:37.0000] <bradleymeck>
moving this to TC39 idk why my brain put this here


2020-10-27
[13:56:20.0000] <littledan>
is this the future of TC39? https://twitter.com/AdamRackis/status/1321191244664578053

[13:56:49.0000] <littledan>
I kinda think we have to have a Barcelona meeting if that's the concept

[13:58:34.0000] <rkirsling>
I like this reply

[13:58:35.0000] <rkirsling>
https://twitter.com/ASpittel/status/1321191825194029060