TC39 Delegates on 2023-07-17

02:22	<snek>	Would any delegate be able to sponsor me as an invited expert (https://github.com/tc39/how-we-work/blob/main/invited-expert.md#joining-process) so I can continue championing/co-championing proposals? I’m leaving Indiana University, a TC39 member. maybe see if openjs foundation will take you as a delegate? https://github.com/openjs-foundation/standards cc ljharb
02:40	<jschoi>	snek: Thanks for that pointer; I’ll reach out to them and see if I can join as a delegate. (In the meantime, if anyone would be willing to sponsor me as an invited delegate, let me know in parallel. Thanks!)
12:30	<ptomato (limited availability)>	I can't commit yet to taking over, but I'd be interested in seeing the state of your branch Mathieu Hofman
12:31	<ptomato (limited availability)>	it looks like the majority of tests using the `async-gc` helper are indeed tests of `cleanupSome`. there is one for `FinalizationRegistry()`, one for `FinalizationRegistry.p.unregister()`, and one for `WeakRef.p.deref()`.
12:32	<ptomato (limited availability)>	so, if `cleanupSome` were withdrawn, we'd need to fix those three tests
13:22	<littledan>	Maybe the University of Utah could join, also? It doesn't cost anything. In general, I do think the Invited Expert system would be a good fit for you, given your past contributions.
14:58	<Chris de Almeida>	University of Utah joining would be ideal, but could take some time for that process. IE is a reasonable stopgap to ensure continuity of access to GH resources, etc
17:32	<Chris de Almeida>	are any of the three `enum` proposals being substantively pursued at this point?
17:32	<Jack Works>	afaik no
17:33	<Jack Works>	I don't have time to do all the things 😭😭😭
17:33	<Chris de Almeida>	there seems to be a theme 🙂
17:34	<Kris Kowal>	I don't have time to do all the things 😭😭😭 big feel™
17:35	<Chris de Almeida>	situation: there are two enum proposals two? ridiculous! we need to develop one universal enum proposal that covers everyone's use cases. yeah! situation: there are three enum proposals
18:47	<bakkot>	Michael Ficarra: btw in the meeting you were asking about my claim that the modal JS developer uses typescript; here's some cites: https://2022.stateofjs.com/en-US/other-tools/#javascript_flavors (click "percent of respondants") https://stackoverflow.blog/2023/06/13/developer-survey-results-are-in/ - 64% of respondents say they use JS, 39% say they use TS. it's pick-all-you-use, so probably most of the people who clicked TS also clicked JS.
18:48	<bakkot>	though the actual claim I wanted to make was "many people have adopted typescript, which will have forced them to learn to do explicit coercions, and that does not seem to have resulted in confusion", and this doesn't rely on TS being a majority, just a large fraction
19:12	<Michael Ficarra>	yeah, I got that from the conversation
19:12	<Michael Ficarra>	apparently TS users are already commonly doing these casts
19:13	<Michael Ficarra>	I'd love to see data on the string-to-number conversions
19:13	<Michael Ficarra>	like what are they doing most commonly and are these actually leading to undesired behaviour for some inputs
19:34	<Chris de Almeida>	some further thoughts on the coercion of primitives: I do not like the conversion of 1,0 to boolean (and similar coercions), but we should not break with long-standing precedent for truthiness/falsiness evaluation. (presuming the `Stop coercing between primitive types` was meant to include boolean coercion, e.g. in params for new methods and conditions) I think `"true"` and `"false"` should be fair game for implicit conversion to boolean, in the same vein as I was suggesting `"2"` and `"3"` should be ok for expected integral values
19:56	<TabAtkins>	`"true"` and `"false"` both convert to `true` today, we absolutely cannot change that.
20:03	<bakkot>	I am mostly OK with coercing strings and numbers to booleans. I am less OK with coercing booleans to strings and numbers. Thoughts on that direction?
20:04	<bakkot>	`"true"` and `"false"` both convert to `true` today, we absolutely cannot change that. the proposal wouldn't be to change that for existing code, just to say that in future boolean-taking APIs, passing any string where a boolean is expected would be a TypeError, rather than implicitly coercing `"false"` to `true`.
20:04	<TabAtkins>	right
20:32	<Chris de Almeida>	that seems reasonable to me, but I'm struggling to think of actual examples of where that would be desirable or expected (boolean to string or number)
23:08	<TabAtkins>	The only use-case that's remotely reasonable is treating bools as 0 and 1 for bitflag purposes.
23:08	<TabAtkins>	For strings tho, no, never.