TC39 Delegates on 2021-10-27

05:45	<Hemanth H.M>	https://hackmd.io/PjvSgvS-Tj-nv3lJl5Dglg?view#1300-15002 15m \| 🕐 `String.cooked` for Stage 1 will be at 13:00hrs or earlier? As we already covered Error Cause on Day-2
09:00	<Rob Palmer>	we are starting plenary now!
09:03	<Aki>	Good morning everyone i'm already one scotch in
09:07	<Michael Ficarra>	seems like we should use stages but go straight to stage 2
09:09	<bakkot>	I'm happy to be a reviewer for 2->3
09:09	<bakkot>	also support stage 2
09:10	<bakkot>	wait, ask for reviewers!
09:12	<Aki>	my b thanks bakkot & yulia
09:13	<shu>	does anyone else see aki in the middle of the stream?
09:14	<shu>	oh yeah was just about to ask
09:14	<Aki>	lol Jitsi just wants to make sure i'm on everyone's mind
09:22	<Michael Ficarra>	why not just "using" and then the expression? why is "using const void" better?
09:34	<Aki>	waldemar: i'm going to delete your topic, if you re-add it to the queue i can move it back to the top.
09:35	<bakkot>	the `await` in a `for await` happens on the line with the `await`
09:35	<bakkot>	it does not seem analalgous
09:36	<shu>	agree, mathieu's point was that it was in the middle
09:36	<shu>	well it does affect control flow, it can throw
09:40	<yulia>	correct me if i am wrong, but isn't this implicit resource management rather than explicit resource management?
09:41	<yulia>	the finally block is implicitly called
09:41	<rbuckton>	why not just "using" and then the expression? why is "using const void" better? `using (expr)` would be a problem, since that's a valid function call
09:41	<ryzokuken>	correct me if i am wrong, but isn't this implicit resource management rather than explicit resource management? exactly! By reading the title, I'd expect a `free` function or something like that 😅
09:41	<yulia>	aki i added my topic back so you can clear me
09:42	<shu>	yulia: well i guess it's explicitly queuing the disposal method up to be called at a different place
09:42	<rbuckton>	implicit would be a destructor, imo
09:43	<Michael Ficarra>	erights makes some good points
09:43	<yulia>	in both cases the disposal method is not explicitly stated by the programmer, but this is a nit
09:43	<yulia>	its not a substantial criticism
09:44	<yulia>	what we have now is explicit, but that comes with the possibility that steps are missed especially during control flow, so i understand the goal here
09:44	<Jack Works>	is it possible to limit `using await` to top of an async function top of an async do expression to resolve the implicit interleaving point problem?
09:45	<bakkot>	Jack Works: not really, you need to do it in a loop body or lots of other places
09:45	<shu>	what are some example of async disposal methods?
09:46	<Jack Works>	Jack Works: not really, you need to do it in a loop body or lots of other places make sense
09:46	<legendecas>	what are some example of async disposal methods? closing a network resource, for example
09:46	<shu>	that's async?
09:46	<Michael Ficarra>	Jack Works: not really, you need to do it in a loop body or lots of other places top of a block?
09:47	<ryzokuken>	I think of it as the `defer myVar.close()` in Golang
09:47	<ryzokuken>	so you'd close the file/socket async to avoid blocking
09:48	<ryzokuken>	but you'd want to definitely do it once the block ends
09:48	<bakkot>	Michael Ficarra: top of a block works, but that's pretty much just `try using` again, right?
09:48	<legendecas>	that's async? in node most of them are async
09:48	<bakkot>	actually why did we go away from `try using`?
09:48	<shu>	i see, thanks
09:48	<Jack Works>	bakkot I want to present this issue https://github.com/tc39/proposal-do-expressions/issues/75 to the committee to get a consensus of adding the restriction I proposed. How do you think?
09:48	<Michael Ficarra>	Michael Ficarra: top of a block works, but that's pretty much just `try using` again, right? SGTM
09:48	<Michael Ficarra>	actually why did we go away from `try using`? apparently feedback from the incubator call
09:50	<bakkot>	Jack Works: I'll bring it up next time I present; I don't think there's much reason to present it before then
09:51	<Jack Works>	Jack Works: I'll bring it up next time I present; I don't think there's much reason to present it before then ok I just want to have that restriction so I can continue to work on the typescript implementation
09:53	<Aki>	about 20 min remaining
09:54	<bakkot>	I am confused about the `Disposable` container - how is `new Disposable(() => foo())` different from `({ [Symbol.dispose]() { foo() })` ?
09:55	<Michael Ficarra>	@bakkot it takes iterables
09:55	<Jack Works>	No difference I guess
09:55	<Michael Ficarra>	an iterable of disposables
09:56	<Jack Works>	@bakkot it takes iterables Isn't `Disposable.from` take iterables instead of the constructor?
09:56	<Michael Ficarra>	Jack Works: yes that's right, was there a constructor too?
09:57	<Jack Works>	I guess it's for DX, `new Disposable(f)` is much easier to write than `({ [Symbol.dispose]: f })`
09:58	<shu>	this example doesn't seem particularly problematic to me
10:00	<Aki>	oh oops i advanced the queue, misinterpreted what Waldemar meant by "let's move on to the next one"
10:01	<ryzokuken>	it's okay, I don't think anyone would begin talking before Waldemar is finished 😇
10:02	<Michael Ficarra>	wouldn't any implicit disposal solution make figuring out tail calls more difficult (for humans)?
10:03	<shu>	maybe in a world where tail calls matter
10:10	<bakkot>	Michael Ficarra made this same point the first time this proposal came up, IIRC
10:11	<shu>	i think RAII is so common new syntax is warranted, abusing for-of seems not great
10:11	<shu>	for reading anyway
10:11	<Michael Ficarra>	eh, I don't think it's an abuse of for-of
10:12	<Michael Ficarra>	in the Scala world, they use `for` for everything and it works nicely for them
10:12	<Michael Ficarra>	(`for` in scala is like Haskell `do` notation)
10:12	<Jack Works>	that `for-of` trick is really cleaver
10:12	<shu>	but in the JS world `for` is for iteration?
10:13	<Michael Ficarra>	shu: not for-of, it's syntax for a protocol
10:13	<Jack Works>	we can use it to not wait for this proposal ship that might take years
10:13	<shu>	we disagree
10:13	<shu>	for-of has a protocol, i would contend very few would understand it as syntax for protocols
10:13	<shu>	it's syntax for iteration
10:14	<Michael Ficarra>	yeah, we just disagree
10:15	<bakkot>	Michael Ficarra: tbf, the protocol literally uses "Symbol.iterator", so I feel like it's fair to say that it is for iteration
10:16	<bakkot>	that said, I also agree that this is a perfectly fine use of for-of
10:16	<bakkot>	lots of languages use `for` like this
10:16	<Michael Ficarra>	it's syntax for interacting with the iteration protocol, but "iteration" can mean many things
10:16	<Jack Works>	why async is a fault? is there any articles I can know the reason? cc yulia
10:16	<shu>	yeah i strongly disagree with the opinion that async/await is a mistake
10:16	<Michael Ficarra>	we iterate over Maybe in our code all the time, and people don't typically think of that as "iteration"
10:16	<shu>	the bugs stem from, well, asynchrony, not the syntax
10:17	<yulia>	why async is a fault? is there any articles I can know the reason? cc yulia it is very tricky to determine a fire and forget bug with async await
10:17	<yulia>	it is very difficult to find just from reading or from static analysis
10:17	<shu>	but the comparison is with Promise handlers, right?
10:18	<shu>	which i feel like has to be harder
10:18	<Mathieu Hofman>	https://github.com/mhofman/disposator
10:18	<yulia>	the other issue with async await is the added viscosity to the language, and the reliance on unnecessarily writing code in a step wise fashion
10:18	<yulia>	i think the space of async code is unsolved
10:18	<yulia>	at least in javascript, this is easier in typed languages
10:18	<Mathieu Hofman>	IMO the iterator approach is not particularly hard to read. Sure it takes a minute to understand why it actually works, but it's not obscure: `for (const {using} of Disposable) { const resource = using(getResource()); }`
10:19	<sarahghp>	i think the space of async code is unsolved I sometimes think the knowledge that `async`/`await` was coming led to less investment in the spaces of Promises and Generators (in particular)
10:20	<yulia>	rbuckton: sorry i cam across strong there
10:20	<Jack Works>	it is very difficult to find just from reading or from static analysis hmm Isn't it save us from promise chain/callback hell? I think it actually improved the readability and static analysis
10:20	<rbuckton>	I'm still looking for another reviewer
10:20	<yulia>	i don't feel like strongly about this
10:20	<yulia>	hmm Isn't it save us from promise chain/callback hell? I think it actually improved the readability and static analysis how does it improve static analysis?
10:21	<yulia>	like, over promises
10:21	<rbuckton>	IMO the iterator approach is not particularly hard to read. Sure it takes a minute to understand why it actually works, but it's not obscure: `for (const {using} of Disposable) { const resource = using(getResource()); }` I still think that, while this is usable, it feels very easy to mistake what's going on here with normal iteration.
10:21	<shu>	it's syntax
10:21	<shu>	it's more analyzable than promise handlers, which are just functions flowing places
10:22	<rbuckton>	rbuckton: sorry i cam across strong there Not a problem, it wasn't my intent to characterize stage 2 in that way.
10:22	<yulia>	right but you can also await non-promises
10:22	<yulia>	so you don't necessarily know anything about what you are awaiting
10:22	<shu>	i think we're assuming different goals of the analysis
10:22	<shu>	i was referring to analyzing the conceptual control flow of the code
10:23	<shu>	what would you like this analysis to answer?
10:23	<yulia>	alright, i mean -- i use async await, my main point is that its highly bug prone
10:23	<rbuckton>	Aki: We advanced topics without getting another Stage 2 reviewer. Waldemar is still willing to review but I'm still missing a reviewer since it seems Yehuda is unavailable.
10:24	<Aki>	shit damn
10:24	<Aki>	sorry
10:24	<shu>	yulia: i feel like that's categorically false, it was an improvement over the Promise handlers and callbacks before that
10:24	<shu>	which were much more bug prone
10:24	<yulia>	the static analysis came up because this has been solved by typescript -- by introducing a promise type, its much easier to track async bugs
10:24	<rbuckton>	Can we add a topic to the agenda to bring this back up after the break?
10:24	<Aki>	yup
10:24	<shu>	if you're making a statement that the absolute bugproneness is still high, then i agree with that
10:25	<shu>	but to characterize it as a "mistake" suggests to me that it was worse than the status quo before it
10:25	<rbuckton>	yulia: If it were just generators/yield, TypeScript doesn't yet have a way to contextually type the result of a `yield` based on its input value. So we can't correctly type an async coroutine built using a generator.
10:26	<yulia>	rbuckton: i didn't mean the generators yield pattern
10:26	<yulia>	i meant the async await pattern in typescript
10:27	<yulia>	the reason i was saying mistake was because i think there was a design space before, that doesn't exist now that we have async await
10:27	<yulia>	i don't think we want to add yet another promise handling syntax
10:27	<yulia>	that would likely be a waste
10:28	<shu>	i see
10:28	<yulia>	and my point around saying it was a mistake was related too "stage 2 is agreed upon" which i brought across too strongly
10:28	<shu>	i can understand being disappointed in not exploring closed avenues
10:28	<shu>	or, rather, not having any reason to anymore
10:28	<yulia>	yep, thats what i have regrets about
10:29	<shu>	but we're not a research language, so eh
10:30	<yulia>	yeah, what can you do
10:30	<Jack Works>	about mistake, I think the biggest mistake is all `then`ables can be awaited. That really cause bugs in my program while I'm using Proxy
10:31	<shu>	oh yeah thenables are terrible
10:31	<danielrosenwasser>	F# does have a few niceties that avoid some of the gotchas that languages like JS have for async/await, but I think async/await in JS is pretty good and pragmatic given all the constraints.
10:31	<yulia>	there is also the kotlin approach but i don't know how much i like it
10:31	<yulia>	though it would address some bugs
10:32	<bakkot>	thenables :(
10:32	<shu>	perhaps you meant thenables 🤡
10:33	<erights>	At Agoric, we found that a simple lintable syntactic restriction on use of await that avoids a large class of bugs: https://github.com/Agoric/agoric-sdk/wiki/No-Nested-Await
10:34	<Jack Works>	that looks like a very subtle bug
10:34	<bakkot>	how do you... not use `await` in a loop
10:36	<erights>	A top level `for await of` loop is fine. We do not have `await` inside the loop. Was surprised that all the in-loop awaits we had were easy to rewrite, and made the code better.
10:36	<bakkot>	the example from this slide of "people storing regexen in a way which doesn't allow them to represent flags" is not compelling
10:37	<Jack Works>	🤔
10:37	<Jack Works>	We have more and more powerful & complicated RegExps
10:37	<Jack Works>	but I never used any advanced features of RegExp (I think it's hard to learn and hard to read)
10:38	<Michael Ficarra>	bakkot: 100% agree, and I think that's the only motivation for the feature
10:40	<bakkot>	I think having part of the regex be case sensitive is a reasonable thing to want
10:40	<Michael Ficarra>	I want to see actual motivating regexps
10:41	<bakkot>	you should say that maybe
10:41	<Michael Ficarra>	bakkot: so we don't need to change arbitrary flags, we need a case-sensitivity modifier? I'd be much more okay with that
10:44	<shu>	at the end of today, i'm going to wish we had that regexp subgroup chip talked about last time (or maybe 2 meetings ago)
10:44	<shu>	i feel like i should care but i don't really
10:45	<yulia>	this isn't my area so... i don't have much of an opinion
10:46	<yulia>	also we don't have an expert on this rn since we are integrating an external engine.
10:47	<yulia>	thanks y'all, btw
10:48	<chipmorningstar>	at the end of today, i'm going to wish we had that regexp subgroup chip talked about last time (or maybe 2 meetings ago) Did I say that?
10:48	<shu>	i thought so! but it's 4am
10:48	<chipmorningstar>	Ah, yes I did.
10:48	<bakkot>	i feel like
10:49	<bakkot>	regexs have a lot of stuff in them already
10:49	<bakkot>	and we are proposing to ~double the number of distinct syntaxes they have
10:49	<bakkot>	seems like
10:49	<bakkot>	a lot
10:49	<shu>	yes, i had thought part of the point of splitting it out is so we could reject some piecemeal
10:49	<chipmorningstar>	When you said "subgroup" I thought you were talking about subgroups inside regexps, instead of regexps inside a subgroup.
10:49	<bakkot>	i would use all of them probably, but
10:49	<bakkot>	it's so many
10:49	<Michael Ficarra>	is it true that this feature is equivalent to `/condition/.test(str) ? /yes-pattern/.test(str) : /no-pattern/.test(str)`?
10:50	<chipmorningstar>	TG4
10:50	<yulia>	i would support tg4 for regex
10:50	<Justin Ridgewell>	Only for really trivial regexes
10:50	<shu>	yes please
10:52	<ljharb>	i'd like to be a reviewer on private field destructuring; i didn't realize stage 2 for it was a possibility.
10:53	<Aki>	good morning Jordan!
10:53	<Michael Ficarra>	ljharb: add yourself as reviewer in the notes
10:53	<ljharb>	k
10:58	<Richard Gibson>	did someone say "ISO 8601 regex"? https://github.com/tc39/proposal-uniform-interchange-date-parsing#background 🙃
11:00	<bakkot>	literally just yesterday I took an extremely long regex and broke it into a sequence of ifs and the code is now much more readable, even though it is also longer
11:01	<shu>	i agree with the abstract notion of meeting users where they are
11:01	<shu>	but, it seems like if the ultimate goal is something like, better TextMate grammar support in VSCode or something
11:02	<shu>	doesn't VSCode have enough adoption to pressure TextMate grammars to express what they need to express without using regexps as a full blown PL?
11:04	<Michael Ficarra>	SURELY there exists some code today that you would want to rewrite using this feature (if it's well motivated)
11:05	<Michael Ficarra>	that can be the example
11:07	<jschoi>	A procedural question: Stage-0 proposals that get presented to plenary should get transferred to the TC39 GitHub organization, right? Like this proposal, if it doesn’t make Stage 1?
11:07	<Richard Gibson>	it does seem to help cases where parts of a pattern must currently be duplicated, but it may not be the best way to do so
11:08	<bakkot>	Richard Gibson: I want to solve that with a better regex builder in the language
11:08	<Richard Gibson>	same
11:08	<bakkot>	every time I build a regex by naive string mashing and `new RegExp` I feel slightly gross
11:08	<bakkot>	most of those times this proposal wouldn't help
11:12	<jschoi>	Incidentally, is a CoC Committee update still going to occur sometime this plenary? I wanted to make sure I didn’t miss that.
11:12	<waldemar>	Lookbehinds can be variable length in ES: /(?<!c[de]*f)abc/.exec("xcfabcdedefabc")
11:13	<jschoi>	Agenda says it happened but notes say it didn’t.
11:13	<Rob Palmer>	I have asked Jory to present a CoC update
11:13	<Michael Ficarra>	if we're process lawyers today, stage 1 entrance criteria includes 'Illustrative examples of usage" which I don't think was satisfied
11:13	<rbuckton>	Lookbehinds can be variable length in ES: /(?<!c[de]*f)abc/.exec("xcfabcdedefabc") My apologies, I am incorrect in that regard. I've spent too much time looking at regex implementations across multiple languages.
11:15	<rbuckton>	if we're process lawyers today, stage 1 entrance criteria includes 'Illustrative examples of usage" which I don't think was satisfied I did provide examples of usage though.
11:18	<rbuckton>	I strongly feel that conditionals improve readability in complex patterns, and can improve readability when you have to context switch between RegExp syntax and JS syntax. I'm also not forging net new syntax here, but asking the committee to consider adopting existing syntax that is a well trodden path across multiple heavily used implementations.
11:18	<Michael Ficarra>	rbuckton: I just want to see some examples where you compare to how you write it today, because I am having a hard time making that comparison myself, so I can't convince myself the feature is needed
11:19	<Michael Ficarra>	rbuckton: I don't think anyone is complaining about the syntax chosen. Being in another regexp implementation isn't motivation, it's guidance on syntax/semantics choices.
11:22	<Michael Ficarra>	if a feature like this is well-motivated, it should be easy for you to find code that was written using facilities that are available today that would've been written using your feature and turned out "better", using whatever definition of "better" you want
11:22	<bakkot>	fwiw I have read a lot of Boost and miscellaneous PCRE regexes and I don't know that I have ever seen a conditional expression; "in a heavily used implementation" isn't really that informative relative to "heavily used in an implementation"
11:25	<rbuckton>	"should be easy" is not so easy when your search criteria is `(?(?=`, but I understand your meaning.
12:00	<Rob Palmer>	Plenary is starting.... now!
12:01	<Bradford Smith>	rbuckton: If the TextMate grammar and related cases (all logic must be in the regex) did not exist, do you think you'd still be motivated to champion the RegExp conditionals proposal?
12:04	<rbuckton>	Yes, I've used it often enough in .NET. I'll admit, it is a niche feature compared to what we already support, but many of the cases where its used its either: The only way to achieve what you want in the regex, vs having to completely break down the regexp. Much easier to read than alternatives.
12:05	<Bradford Smith>	maybe you still have access to the .NET examples where you've used it then?
12:06	<bakkot>	this doesn't seem like a pun to me?
12:07	<shu>	nor to me
12:07	<bakkot>	a pun is when you are using a word in a non-obvious way
12:07	<rbuckton>	Nothing I could locate quickly, I've spent most of my time in JS/TS for the last 6 years.
12:07	<bakkot>	but "raw" and "cooked" are antonyms
12:07	<Michael Ficarra>	raw/cooked may be duals in the food preparation space, but I'm not sure String.raw is in any way a "dual" of String.cooked
12:07	<jschoi>	Raw isn’t just a food term. Raw supplies, for example.
12:07	<jschoi>	Raw material.
12:08	<shu>	yes, words have multiple meanings
12:08	<yulia>	yeah i am not sure about "cooked" here
12:08	<shu>	i kinda like it
12:08	<waldemar>	I prefer something like "processed". I had no idea what "cooked" meant.
12:08	<ryzokuken>	I'd prefer a name that is describes better what it does (atleast somewhat).
12:09	<jschoi>	Cooked isn’t necessarily just a food term either.
12:09	<jschoi>	Although its association with cooking is stronger than raw’s.
12:09	<bakkot>	"processed" doesn't mean anything at all to me
12:09	<bakkot>	every function processes its inputs
12:10	<shu>	i'm fine with `identity` as well
12:10	<shu>	would not prefer "processed"
12:10	<yulia>	baked.
12:10	<Michael Ficarra>	to be fair, I initially had to have the relationship between "cooked" and "raw" explained to me
12:10	<yulia>	it should be baked
12:10	<rbuckton>	In the issue tracker I proposed `String.interp` or `String.interpolate` for just basic interpolation
12:10	<jschoi>	Baked also is not necessarily a food term either.
12:10	<jschoi>	Oops, I’m up.
12:11	<shu>	you're still ingesting something i guess
12:11	<shu>	close enough
12:11	<Michael Ficarra>	String.ingested
12:12	<yulia>	digest might actually work
12:12	<shu>	oh no that's too overloaded with hash stuff
12:12	<rbuckton>	digest makes me think about hashing/signing
12:12	<rbuckton>	what shu said
12:12	<yulia>	ah, nevermind
12:13	<sarahghp>	In the issue tracker I proposed `String.interp` or `String.interpolate` for just basic interpolation I like `interpolate`
12:14	<ryzokuken>	ga-zem-nid?
12:14	<sarahghp>	also `process`
12:14	<sarahghp>	nothing about ingesting! 😱
12:14	<rbuckton>	"cooked" makes sense in reference to the actual specification text: 13.2.8.3 GetTemplateObject ( templateLiteral ) Step 5: `Let cookedStrings be TemplateStrings of templateLiteral with argument false.` Step 11.b: `Let cookedValue be cookedStrings[index].`
12:14	<Justin Ridgewell>	If we go with `processed`, we could subtly continue the `raw` metaphor
12:15	<ljharb>	the spec text can easily change its terminology to better reflect users' mental models
12:15	<shu>	why are people shipping so much `console.log`?
12:15	<rbuckton>	diagnostic logging?
12:15	<Michael Ficarra>	I think I only use call when it's bound, to turn a function of n parameters in to a function of n+1, where the first is the this-value: `const blink = Function.prototype.call.bind(String.prototype.blink); blink('DHTML')`
12:16	<ljharb>	why are people shipping so much `console.log`? it's totally fine for anything running in node to use it in production
12:16	<ljharb>	Michael Ficarra: call-binding is definitely my primary use case - but that's also because it bypasses the need to `.call` later on the call-bound thing
12:16	<yulia>	I like the thinking here a lot
12:17	<shu>	i find any natural language - PL connection fairly tenuous
12:21	<shu>	i do like and appreciate the simplicity
12:21	<Michael Ficarra>	how would I define my `blink` function from above using this new feature?
12:22	<ljharb>	`const { blink } = String.prototype; const callBoundBlink = blink::blink.call;` i think? but you don't need the call-bound one either; you can do `str::blink()` any time
12:23	<rbuckton>	You asking for a way to uncurry `this`, which is kind of the opposite of what this does (though you can do it using this syntax and `.call`).
12:24	<rbuckton>	Partial Application would be `String.prototype.blink.call~(?)` (binds Reference to `blink.call`)
12:24	<Richard Gibson>	`this::smartRound~(params.floatPrecision)` looks bad to me
12:24	<ljharb>	for all my use cases, the "uncurry this" pattern (which i call "call-binding") is completely unnecessary with the `::` calling syntax, since its sole purpose is to robustly change the receiver later
12:25	<sarahghp>	It seems like a large number of cases of `bind` are for partial application. Were those taken out?
12:25	<sarahghp>	If this doesn't support partial application?
12:25	<ljharb>	erights: pipe and `.call` wouldn't let me be robust against `delete Function.prototype.call`
12:25	<yulia>	we had seen the opposite -- that bind is usually for binding `this`
12:25	<yulia>	its a common pattern for example in jsx
12:26	<sarahghp>	binding this or the partial application?
12:26	<yulia>	binding this
12:26	<sarahghp>	for JSX, I have partial, but that's functional components ... I guess old react is classes
12:26	<yulia>	partial application is much less frequent as a use for `bind`
12:26	<Michael Ficarra>	yulia: JSX isn't shipped to the browser though, right?
12:26	<Michael Ficarra>	so it can compile to a bind call?
12:26	<yulia>	no, but we are sensitive to how people are using the language
12:27	<yulia>	and there are other cases of bind outside of react, it was just the immediate example that came to mind
12:27	<yulia>	i think js choi did some great corpus analysis for this
12:27	<ljharb>	can someone advance the queue to indicate mark's topic is up?
12:28	<Michael Ficarra>	You asking for a way to uncurry `this`, which is kind of the opposite of what this does (though you can do it using this syntax and `.call`). I see now, thanks. You're right, it looks to be the opposite.
12:28	<sarahghp>	i think js choi did some great corpus analysis for this do you know, is that in the repo? (I'm just a curious student driver lol)
12:29	<bakkot>	I want to explicitly oppose jhd's motivation here
12:29	<Michael Ficarra>	bakkot: YOU DO THAT TOO!
12:29	<bakkot>	that is: I think this should be an extremely low-weight factor
12:29	<bakkot>	Michael Ficarra: yeah, but I know that I'm weird
12:29	<ljharb>	that's fine
12:29	<bakkot>	we're super weird
12:29	<yulia>	do you know, is that in the repo? (I'm just a curious student driver lol) https://github.com/js-choi/proposal-bind-this#bind-and-call-are-very-common
12:29	<shu>	bakkot: +1
12:31	<Michael Ficarra>	basically every module I ever write, I protect against later-run code overriding or deleting built-ins, and so should everyone
12:31	<ljharb>	it's reasonable not to expect people to write unergonomic code to achieve that. but if we can provide a way to make robust code easier, how are we not incentivized to do so?
12:35	<bakkot>	michael: no you do not
12:35	<bakkot>	this is false
12:35	<bakkot>	I have seen you write `.map` many times
12:35	<rbuckton>	basically every module I ever write, I protect against later-run code overriding or deleting built-ins, and so should everyone Someday I hope we can do better, because that's an unreasonable expectation for the majority of JS devs.
12:35	<Michael Ficarra>	I have seen you write `.map` many times blasphemy!
12:36	<Sergey Rubanov>	Is old bind operator proposal withdrawn? It's in stage 0 list
12:36	<ljharb>	no
12:36	<ljharb>	but it would be if this one made it to stage 2
12:37	<ljharb>	Someday I hope we can do better, because that's an unreasonable expectation for the majority of JS devs. it is now. but it shouldn't be.
12:37	<erights>	For all those proposing new syntax especially, please reread https://erights.medium.com/the-tragedy-of-the-common-lisp-why-large-languages-explode-4e83096239b9
12:38	<ljharb>	legendecas: regarding your queue item, typically competing proposals in stage 1 is fine, once one advances to stage 2, the alternatives typically are withdrawn
12:38	<rbuckton>	it is now. but it shouldn't be. I have thoughts on this related to concurrent JS and shared structs, but nothing formal yet.
12:39	<bakkot>	Michael Ficarra: https://github.com/michaelficarra/samevalueset/blob/e1a5b6ea5d1336ea42908e7061ba3a03536624bd/src/index.js#L31
12:39	<bakkot>	not `.map` but close enough
12:39	<rbuckton>	If we had PFA and bind-this, `o::f` would be synonymous with `o::f~(...)` (though more terse).
12:39	<ljharb>	grepping actual code on github for counterexamples is a dirty trick :-p nobody compare my style recommendations to a minority of my actual code please
12:40	<rbuckton>	Which might reduce the motivation for non-call `o::f`, but only if PFA advances to stage 2+.
12:41	<Michael Ficarra>	not `.map` but close enough to be fair, I did go to some effort to make that code robust (using call-bound call to call callbacks), just missed that case
12:41	<shu>	yulia: my understanding of pipeline is about reducing "dimensionality" (i.e. flattening nesting, which is harder to mentally process), not ordering per se
12:42	<yulia>	the reason nesting is hard to read is that you have to process it backwards was my understanding
12:42	<shu>	research on how word order matters sounds interesting however, links?
12:42	<yulia>	felienne's work on reading code
12:42	<rbuckton>	What are the competing rivals for bind-this? The old bind proposal and extensions? PFA is not a competing rival, though it is cross cutting and shares some functionality.
12:42	<shu>	i'm skeptical of that claim because there are pelnty of non-SVO languages that are just as easy to to comprehend?
12:42	<yulia>	i believe she presented it last year, i can find the links
12:42	<shu>	nesting is difficult because you need to track a stack of state
12:43	<yulia>	can i get a definition of svo?
12:43	<ljharb>	rbuckton: yes, those are the two. not PFA.
12:43	<shu>	e.g. center embeddings in english are hard to understand
12:43	<bakkot>	Michael Ficarra: literally a majority of the method calls in this module are not robust against prototype pollution
12:43	<shu>	subject-verb-object word order
12:43	<yulia>	ah yes, thanks
12:43	<yulia>	yes, this is true, but we currently don't have true internationalization of programming languages
12:43	<bakkot>	also if you are trying to be defensive against prototype pollution you can't use `...` with arrays, including in function arguments
12:43	<bakkot>	it's just not a realistic concern
12:44	<yulia>	this is also openly being explored, the defacto grammar and understanding of programming languages is english right now
12:44	<yulia>	this is also reflected in how we define grammars and parsing
12:44	<shu>	this is also reflected in how we define grammars and parsing oh?
12:45	<yulia>	yes, there was an interesting presentation on this in pilates (programming in languages other than english) conference
12:45	<ljharb>	that is true, and something node core already has to deal with, and that `::` can actually solve by using it with the extracted Symbol.iterator method.
12:45	<yulia>	or, i think i got the acronym wrong
12:46	<yulia>	https://icer2021.acm.org/getImage/orig/Programming+In+Languages+that+Aren%E2%80%99T+English.pdf
12:46	<bakkot>	ljharb: how does `::` help with making `function f(...args){}` robust against prototype pollution
12:46	<bakkot>	or even `f(...args);`, for that matter
12:47	<legendecas>	delete Function.prototype.call
12:47	<ljharb>	the first one doesn't use the protocol; the second can't be protected, that is true. i was speaking to iteration use cases for mitigation.
12:47	<rbuckton>	delete Function.prototype.call The problem is you can also `delete Array.prototype[Symbol.iterator]` and break the code.
12:48	<rbuckton>	at least, the `f(...args)` case.
12:48	<Michael Ficarra>	I cannot wait to have `groupBy`! ❤️
12:49	<yulia>	omggggg maybe yes!
12:49	<rbuckton>	My primary motivation for PFA (and bind-this) is convenience, not prototype pollution. Its a nice bonus, but a much smaller concern to me.
12:49	<Michael Ficarra>	I don't even think this one would be the first to ignore species, right?
12:50	<shu>	nope
12:50	<shu>	at least Temporal
12:50	<Michael Ficarra>	the immutable array methods ignore it, I believe
12:50	<shu>	also resizable buffers
12:51	<annevk>	This the right time to ask how likely it is that species will be removed?
12:52	<shu>	well
12:52	<ljharb>	lol you can ask :-p
12:52	<Michael Ficarra>	annevk: removed? removed how?
12:52	<shu>	somebody that's not me need to find time in the next 1-2 years to actually build a custom V8 that lets you toggle species-handling, and seeing what breaks
12:52	<Michael Ficarra>	Symbol.species will continue to exist, if that's the question
12:53	<ljharb>	don't tempt fate justin
12:53	<shu>	we should name this `sort`
12:53	<shu>	because that's what that word actually means
12:54	<yulia>	This the right time to ask how likely it is that species will be removed? we hit some snags..
12:54	<yulia>	but, hopefully can start looking into it again in the new year
12:54	<rbuckton>	I'm much more interested in `groupByMap` for most places where I'd use this, since I'd like to have non-string/symbol keys, but I'm not against it.
12:54	<yulia>	there is a library that is heavily using it
12:54	<shu>	what, core-js?
12:54	<yulia>	yeah
12:54	<yulia>	im not convinced it is impossible yet
12:55	<rbuckton>	IIRC, all of core-js usage of Symbol.species is purely to emulate spec behavior for shims that use Symbol.species.
12:55	<shu>	yeah i don't feel like those are real uses
12:55	<shu>	exactly, yeah
12:55	<yulia>	there is a possibility that other browsers can use the chrome escape hatch that was built in there
12:55	<shu>	the real difficulty there is i now refuse to engage with the author of core-js
12:55	<yulia>	i can understand why
12:55	<nicolo-ribaudo>	And also, `core-js` has a big number of downloads but just because it includes every polyfill, not because of `Symbol.species`
12:56	<rbuckton>	If core-js had a way to conditionally not shim/use Symbol.species, I expect it would be less of a problem.
12:56	<yulia>	yes exactly
12:56	<ljharb>	100% agree that core-js's usage of these things shouldn't be weighted highly (also any polyfills/shims, including my own)
12:56	<yulia>	i did a test run with core-js and the libraries that were listed
12:56	<ljharb>	it's not breaking the web to cause unnecessary polyfilling
12:56	<yulia>	and there were breakages that i found, but i didn't have enough time to fully clear the issue raised
12:56	<yulia>	and i didn't want to engage further
12:56	<yulia>	we have an implementation in FF for testing
12:57	<shu>	oh awesome you already did an implementation?
12:57	<yulia>	yes, with the different grades
12:58	<shu>	oooo
12:58	<shu>	where's the patchstack?
12:59	<yulia>	its from last year, let me ask the author (can't find it rn)
12:59	<jschoi>	sarahghp [regarding `.call` corpus analysis]: Note that the methodology details are hidden in a `<details>` disclosure element at the end of the section. There’s also manual-review data in issue #12.
13:01	<bakkot>	+1 to throwing for `plain` with strings with `Z`
13:01	<yulia>	where's the patchstack? here it is https://phabricator.services.mozilla.com/D101832
13:01	<yulia>	its without deleting it, its just disabling it
13:01	<shu>	yulia: ty
13:02	<shu>	right, i had similar plans for a V8 flag but can't find the time to actually code it up
13:02	<yulia>	yeah, we should do a run of an experiment with it but i keep not finding the time
13:11	<shu>	ptomato: is ftang in the loop for all these normative changes and bug fixes?
13:11	<shu>	because i sure as hell won't remember to check these
13:12	<ljharb>	iirc ftang discovered many of them
13:12	<shu>	yes, but didn't know if it was all of them
13:13	<shu>	i have a hard enough time reviewing the implementation, just wanted to check i also didn't have to keep up with the normative changes and fixes
13:15	<ryzokuken>	I think if there's someone on top of all this, it has to be ftang...
13:19	<Justin Ridgewell>	Doh, I forgot to ask for Stage 3 reviewers
13:20	<Michael Ficarra>	oh no
13:20	<Justin Ridgewell>	We can make it informal
13:20	<ljharb>	i'd love to review array grouping
13:20	<Michael Ficarra>	we really need to figure out a strategy for not forgetting that
13:20	<Michael Ficarra>	Justin Ridgewell: I will review for you
13:20	<Justin Ridgewell>	Whoot
13:20	<Michael Ficarra>	still ask, though
13:20	<Justin Ridgewell>	Thanks Jordan/Michael
13:22	<Sergey Rubanov>	I'd love to review array grouping too
13:24	<bakkot>	I feel like "an options bag which must provide one of these two options" is not actually that confusing?
13:25	<ljharb>	it can be very hard to figure out what one did wrong with APIs like this, at any experience level. good error messages help but aren't always sufficient.
13:25	<shu>	bakkot: strong +1
13:28	<rbuckton>	we really need to figure out a strategy for not forgetting that Add a "Stage 3 Reviewer Sign-up" feature to tcq?
13:30	<rbuckton>	Or even just a general "Stage Advancement" feature that adds something to an agenda topic that can show up in the queue as part of advancing the topic, with an option to allow reviewers to sign up when necessary.
13:32	<bakkot>	i kinda like WH's solution of just making it optional and then it doesn't round to anything
13:32	<bakkot>	but I don't share ljharb's intuition that options bags should themselves be optional
13:34	<waldemar>	I'm not saying that the options bag should be optional. But if you pass an options bag without a smallestUnit, then round should be the identity.
13:36	<Michael Ficarra>	Or even just a general "Stage Advancement" feature that adds something to an agenda topic that can show up in the queue as part of advancing the topic, with an option to allow reviewers to sign up when necessary. feature request: https://github.com/bterlson/tcq/issues/45 /cc bterlson
13:43	<ljharb>	justingrant: ftr i'm not happy with Duration round's API still, but i agree it's better to have the string shortcut with smallest and the options bag with "smallest or largest" than the status quo, especially considering the other methods would all be using the ergonomic string shortcut pattern
13:43	<Mathieu Hofman>	I wouldn't block for overloading of string and options bag, but I'd ask that it only be used when it really improves the ergonomics and that there is no confusion possible as to what default setting is set
13:45	<Mathieu Hofman>	IMO requiring that an object is always present is not an issue if some config is always required. If all options are optional, an empty object and no object should be equivalent
13:46	<ljharb>	super agree that empty and no object should be equivalent, and that the pattern should not be used when there's confusion about what the default should be (and only when the pattern improves ergonomics)
13:46	<shu>	i'm confused then
13:47	<ljharb>	about which part
13:47	<shu>	i'd take Mathieu Hofman's position to also mean that it's not problematic for A() to take an optional options bag and B() to take a required options bag of the same shape (with >1 required properties)
13:47	<shu>	but ljharb you find that problematic?
13:48	<ljharb>	i find ">1 required properties" or anything more complex than "1 specific required property" problematic
13:49	<bakkot>	can you say more about where that intuition comes from?
13:49	<shu>	okay, then we still disagree, i find that fine
13:49	<ljharb>	bterlson: advance queue?
13:49	<bakkot>	I feel like... it is pretty common to have things like "you must specify either an X or a Y"
13:49	<shu>	right
13:49	<shu>	config objects can have fairly involved, but still intuitive logic to them
13:49	<annevk>	Just grep a browser's .webidl files for `required` if you need some prior art
13:49	<ljharb>	from confusion i've experienced and witnessed many others experience when they misuse such APIs. It is … not uncommon to do that. that's why i don't like it, because i run into it often enough.
13:50	<shu>	like, implications
13:50	<ljharb>	config objects are a PITA to work with
13:50	<bakkot>	I agree people get confused about these sometimes but like
13:50	<bakkot>	people get confused about lots of stuff
13:50	<bakkot>	I don't think these are inherently confusing
13:50	<shu>	yes, i agree with that too, but the confusion stems from the fundamental complexity of configuration
13:50	<shu>	yes exactly
13:50	<ljharb>	and when it's unavoidable - like Duration round - maybe that's fine. but when it's avoidable we should avoid it.
13:51	<shu>	i think you're confusing the source of confusion -- you can say, there needs to be fewer options, and Apple would agree
13:51	<ljharb>	if i had a better idea for Duration round i'd suggest it, but i don't
13:51	<shu>	but sometimes the problem space just sucks
13:51	<ljharb>	i don't mind lots of optional options :-)
13:51	<shu>	but that's not a complicated case
13:51	<ljharb>	and nobody disputes that temporal's problem space is a hellish nightmare
13:51	<shu>	i think the disagreement is, i don't think you can wave away inherent logic required in many config objects
13:51	<shu>	including mutual exclusion, implication, etc etc
13:52	<shu>	you can't wave that away by trying to adopt linter-like rules like "options bags must be optional"
13:56	<shu>	bakkot: that error message is gonna get so many complaints
13:56	<ptomato>	ptomato: is ftang in the loop for all these normative changes and bug fixes? yes, he found most of them, but I am pretty sure he read the slides as well. I'll double check at the next Temporal meeting
13:56	<shu>	excellent, thank you
13:56	<bakkot>	`let value = /regex#/ a+b/x`
13:56	<bakkot>	is ambiguous
13:58	<nicolo-ribaudo>	Uh well, if we are going to require balanced brackets in `(#...)` comments we might as well disallow `/` in line comments
13:59	<nicolo-ribaudo>	Nvm, it would probably make parsing that code a nightmare
13:59	<shu>	big +1 to not changing permissive grammar here
13:59	<shu>	i will probably refuse to implement that change out of fear
14:00	<Michael Ficarra>	uhh I think we've been without a notes curator for a little bit
14:00	<Michael Ficarra>	anyone who participated in the last discussion, please help edit the recent notes
14:08	<bakkot>	think we got it mostly cleaned up
14:08	<bakkot>	the discussion portion at least
14:08	<bakkot>	talk portion is still a bit mangled, but mostly readable
14:09	<Michael Ficarra>	looks good, thanks everyone
14:35	<Hemanth H.M>	Was it rbuckton who agreed to be a reviewer for `String.cooked`? Trying to recall (yes, will check the notes too)
14:38	<Hemanth H.M>	NVM, it is Richard Gibson thank you!
14:50	<ptomato>	bterlson: is the remaining point for Temporal already on the list of overflow topics for tomorrow or should I request that somewhere in particular?
20:22	<rbuckton>	shu it sounded like no one wants to touch RegularExpressionLiteral? It seems like it would be feasible to balance `(?#` and `)` so as to allow an unbalanced `[]` inside a comment. I'm not sure I fully understand the reticence to make changes here.
20:30	<Richard Gibson>	I suspect it is a desire for stability of tokenization to accommodate software already present in the ecosystem, but regardless I agree that it should be explicitly articulated