TC39 Delegates
2022-01-24
plaintext logs
prev next
source on github
09:18
<Jack Works>
👀 is there drafted agenda for this meeting so I can schedule my sleeping time? thanks!
11:14
<yulia>
jschoi: i have a dumb question, what if promise.all accepted async iterators (it already takes iterables), instead of doing that in a separate API? re: https://github.com/tc39/proposal-array-from-async
13:28
<Rob Palmer>
The draft schedule for today's meeting is now posted: https://github.com/tc39/Reflector/issues/411
13:31
<Luca Casonato>
The draft schedule for today's meeting is now posted: https://github.com/tc39/Reflector/issues/411
Thanks! 🙏
15:59
<jschoi>
jschoi: i have a dumb question, what if promise.all accepted async iterators (it already takes iterables), instead of doing that in a separate API? re: https://github.com/tc39/proposal-array-from-async

Promise.all’s current semantics involve parallel awaiting of input values. If some input yields a, b, c, then Promise.all(input) would first drain input into its three items a, b, c, and then it would simultaneously await a, b, c.

Parallel awaiting is impossible when getting values from async iterators; we must sequentially await for the values.

I think it would be quite confusing if Promise.all did parallel awaiting on sync inputs and sequential awaiting on async inputs. This is the similar to how it would be confusing if for await did parallel awaiting on sync inputs but sequential sequential awaiting on async inputs. Hopefully that makes sense.

16:00
<yulia>
I see, thanks!
17:48
<Rob Palmer>
We will start the meeting in 12 minutes!
18:24
<leobalter>

I like the formal votes, but fine with it going without it.

I also have no opposition to ryzokuken being on both roles (402 Editor + TC39 Co-Chair).

18:50
<bakkot>
we could in theory make a bot to download issues but I don't wanna do it
18:55
<bterlson>
bakkot: is the ecmarkup change an API change or breaking in the sense that new things in the biblio will change where links go/what links/etc.?
18:55
<bterlson>
just curious
18:56
<ljharb>
Rick Waldron: can you confirm that https://github.com/tc39/proposal-modules-pragma should become an inactive proposal?
18:57
<Rick Waldron>
ljharb: That was true in 2017. I have no further information that changes that status
18:58
<ljharb>
ok thanks, i'll update the repo and the proposals list to mark it as such. would you call it "rejected' or "withdrawn"?
18:58
<Rick Waldron>
ljharb: lemme check the notes, one sec.
18:59
<rbuckton>
possible bot autocorrect needed: "x markup" -> "ecmarkup"
18:59
<bakkot>
bterlson: main change is that the biblio will not be built in, and you'll have to specify --load-biblio=file/package to get the biblio
19:00
<bakkot>
so it can be updated independently of ecmarkup
19:00
<bakkot>
(in particular the plan is to release a new biblio with every commit to the spec, or at least every one which affects the biblio)
19:01
<Rick Waldron>
ljharb: I cannot find discussion of record, but I would not pursue it myself in 2022, or any year... I can't even remember why I thought it was an idea to explore at the time.
19:01
<Michael Ficarra>
thank you for the feedback on this topic, sffc :-)
19:02
<Rick Waldron>
ljharb: I cannot find discussion of record, but I would not pursue it myself in 2022, or any year... I can't even remember why I thought it was an idea to explore at the time.
I may have been doing a favor for a community member
19:02
<ljharb>
ljharb: I cannot find discussion of record, but I would not pursue it myself in 2022, or any year... I can't even remember why I thought it was an idea to explore at the time.
as i recall, it was around the time of the fauxtrage about .js and ESM in node
19:02
<ljharb>
i'll mark it as just being "inactive"
19:02
<bterlson>
@bakkot sounds great, it's super annoying for non-262 uses to have the biblio there at all :-P
19:03
<Rick Waldron>
as i recall, it was around the time of the fauxtrage about .js and ESM in node
Which would TOTALLY support my suspicion that I was "proxy-championing" this
19:03
<yulia>
This is so amazing shu
19:03
<sffc>
yulia Michael Ficarra Here is a discussion from October (https://github.com/tc39/ecma402/blob/master/meetings/notes-2021-10-07.md#normative-add-new-numbering-system-tnsa) and another from January (https://github.com/tc39/ecma402/blob/master/meetings/notes-2022-01-13.md#normative-add-new-numbering-system-tnsa)
19:03
<Rick Waldron>
That is something I would've done: tell a community member to write a solution and that I would present it in good faith.
19:03
<shu>
thanks! kevin helped a lot too with the ecmarkup stuff needed
19:04
<Rick Waldron>
But it looks like they never really pushed forward on it, and since I was acting in a proxy role, I wouldn't have done any extra work beyond reporting to committee.
19:09
<bakkot>
there's actually already a --no-ecma-262-biblio which tells it not to load the built-in one
19:10
<yulia>
sffc: per anba's comment here (https://github.com/tc39/ecma402/pull/614#issuecomment-938638422) i don't think we have any comments but i will clear it with our intl team
19:13
<waldemar>
How do you annotate that something doesn't call user code?
19:15
<bakkot>

waldemar: https://github.com/tc39/ecma262/pull/2548 describes guidance for spec authors, relevant part of which is

False positives can be manually suppressed with <emu-meta suppress-effects="user-code">suppressed</emu-meta>.

19:15
<Michael Ficarra>
waldemar: if you need to do it manually, like this: https://github.com/tc39/ecma262/pull/2548/files#diff-181371b08d71216599b0acccbaabd03c306da6de142ea6275c2135810999805aR18446
19:15
<Michael Ficarra>
but mostly it's implied by !
19:16
<shu>
@waldemar: you can wrap the abstract operation / SDO call in <emu-meta suppress-effects="user-code">AbstractOp()</emu-meta>, but yeah as Michael Ficarra says ! implies the suppression
19:24
<shu>
for spec authors, the tests in this file also serve as a good tutorial for how to annotate, but hopefully most spec drafts require no additional work: https://github.com/tc39/ecmarkup/blob/main/test/baselines/sources/effect-user-code.html
19:39
<yulia>
whatwg on polyfils: https://w3ctag.github.io/polyfills/
19:41
<Michael Ficarra>
whatwg on polyfils: https://w3ctag.github.io/polyfills/
that document is broken for me
19:41
<shu>
did my queue item get deleted?
19:42
<shu>
Rob Palmer: ^
19:43
<ryzokuken>
that document is broken for me
took a second for me
19:44
<ryzokuken>
perhaps the CSS load is non-blocking
19:44
<Rob Palmer>
sorry shu I did not see you on the queu
19:45
<Rob Palmer>
put yourself back on and i shall re-order - just tell me where it should go
19:45
<shu>
hm, pretty sure i added myself, guess i'll re-add myself to the end
19:45
<Rob Palmer>
i can move you up
19:45
<yulia>

in that doc they have

* **polyfill**: Emulates a well established feature of the web platform
* **speculative polyfill** (aka 'ponyfill', 'prollyfill', 'nottifill'): Emulates a proposed feature of the web platform
* **library** (aka 'module'): Provides features or functionality not anticipated to be a web platform feature
19:45
<shu>
Rob Palmer: after J. S. Choi is done is good
19:46
<Rob Palmer>
actually you're already there!
19:46
<Rob Palmer>
just refresh - tcq bug :-(
19:47
<shu>
oh weird :(
19:48
<yulia>
jschoi: i didn't have time to respond, but yes feature detection is a problem
19:49
<yulia>
though i wonder if it makes sense to include this in the document. Experiment should be treated as not in production code
19:50
<TabAtkins>
Here's the published version of the TAG finding, which is not broken: https://www.w3.org/2001/tag/doc/polyfills/
19:51
<TabAtkins>
Also note that this is not WHATWG, it's the W3C TAG.
19:51
<yulia>
I feel like this could be cited?
19:51
<ptomato>
Also note that this is not WHATWG, it's the W3C TAG.
oh, my bad
19:51
<Michael Ficarra>
I just don't think anything will tangibly change, whatever recommendation we make
19:51
<yulia>
clarity is helpful though
19:53
<Michael Ficarra>
I haven't had time to review the document we're being asked to voice our support for
19:53
<Michael Ficarra>
maybe we come back with a modified proposal that references the document next time?
19:54
<yulia>
Yeah, that makes sense
19:55
<ljharb>
for the specific wording, that's fine, but i still wanted to get consensus on the conceptual change, to avoid distractions in the PR.
19:57
<yulia>
we may need to change 3.5 of that document...
19:58
<ljharb>
3.5?
19:59
<yulia>
https://www.w3.org/2001/tag/doc/polyfills/#detect-and-defer-to-native-implementations
19:59
<Michael Ficarra>
yeah, that sounds like the opposite of what we would advise
20:00
<TabAtkins>
Note that that's explicitly guarded by "past the tipping point", aka things that are already well-decided and implemented in some browsers, and thus very unlikely to change.
20:01
<TabAtkins>
It explicitly warns against doing this before that point, and has examples of the "grab the native if it exists, otherwise use the polyfill" pattern as explicitly discouraged.
20:02
<yulia>
hmmm, maybe we can define tipping point clearly
20:02
<yulia>
but even then , it seems liable to being misinterpretted..
20:03
<Michael Ficarra>
ah, thanks TabAtkins I misread it
20:24
<yulia>
I think tab is right, this aligns with our goals it looks like. if we need clarifications we can post on the TAGs design issue tracker
20:55
<yulia>
is ptomato ready to go?
20:59
<ptomato>
I am
20:59
<yulia>
great
21:18
<bakkot>
motion to close this discussion and move on, no one disagrees with the proposal afaict
21:19
<leobalter>
well, I appreciate everyone having clarity on the topics we discuss
22:15
<ljharb>
would this document basically be like a new TG?
22:16
<ljharb>
i can ask that on the queue if it wouldn't derail the ending of the item
22:17
<yulia>
is 404 a tg?
22:17
<ljharb>
i think so
22:17
<ljharb>
actually i dunno, maybe not
22:17
<yulia>
we also have the spec suite as a document
22:17
<yulia>
i see this as closer to one of those
22:18
<ljharb>
since there's just tc39, 402, and security
22:18
<ljharb>
k
22:18
<yulia>
i still want it to be 405
22:19
<shu>
ljharb: i don't see it as a TG, no
22:19
<shu>
the IP-making body is still TG1
22:19
<shu>
it just goes into a separate document than ecma262
22:20
<ljharb>
cool
22:20
<shu>
i don't know how to legally set that up but i'm not too worried about it?
22:21
<ljharb>
can prolly just make a repo for it when we're at that stage, which i'm now empowered to do
22:54
<Bradford Smith>
When did the "structured clone" discussion start? I really thought it started before 2pm. Isn't the time box spent?
22:55
<bakkot>
Bradford Smith: meeting's over
22:55
<bakkot>
this is post-plenary me picking mark's brain
22:56
<Bradford Smith>
oh, thx
23:49
<bakkot>
ljharb: can you use your admin powers to drop a link to https://github.com/bakkot/proposal-duplicate-named-capturing-groups on https://github.com/tc39/proposal-regexp-named-groups/issues/44 ?
23:50
<bakkot>

also, new (small) regex proposal I intend to put together for next meeting: allow capture group names to be re-used (when in different | alternatives) rather than enforcing uniqueness in the full regex

https://github.com/bakkot/proposal-duplicate-named-capturing-groups