| 11:20 | <James M Snell> | For today's continuation discussion on TypedArray concat ... I've been able to update the problem statement in a way that addresses dminor's concerns but there's still enough of an open question around iterable support that I'm going to defer asking for Stage 2 and instead just see if we can settle some of the questions around iterable support as documented in this comment: https://github.com/tc39/proposal-typedarray-concat/issues/8#issuecomment-4045546879 ... mentioning here now so folks interested in the discussion might have some time to gather thoughts |
| 11:24 | <James M Snell> | Chris de Almeida or Rob Palmer ... if there's time on the agenda for another continuation, I believe that https://github.com/tc39/proposal-typedarray-findwithin/pull/9 should sufficiently address the discussion around TypedArray findWithin to move forward with the ask for Stage 2. Can I ask for a 15 minute continuation on it? |
| 13:47 | <Michael Ficarra> | @James M Snell I'm really worried about lastIndexOfSequence. That sounds like it gives you the index at the end of the sequence. I think it should be indexOfLastSequence or something. |
| 13:55 | <James M Snell> | Fair |
| 13:57 | <bakkot> | I do not have the same intuition about those names fwiw |
| 13:57 | <James M Snell> | I'm terrible at naming so I'm happy to go with whatever suggestion seems the best to y'all so that's a change I can make :-) |
| 13:57 | <bakkot> | "last index of sequence" sounds like it gives the last index where the sequence is |
| 13:58 | <bakkot> | which... is what it does |
| 13:59 | <Rob Palmer> | The meeting is starting in 30 seconds!!! |
| 13:59 | <peetk> | seems ambiguous at best |
| 13:59 | <Michael Ficarra> | yeah the last index where the first occurrence of the sequence is |
| 14:01 | <bakkot> | if we didn't already have lastIndexOf I could maybe imagine having that intuition, but we do |
| 14:06 | <James M Snell> | alternative idea: drop the second operation entirely and allow a native (search from the end) position argument on...
|
| 14:07 | <bakkot> | indexOf already supports a negative index and it's very useful |
| 14:07 | <bakkot> | this is not a substitute for lastIndexOf |
| 14:08 | <James M Snell> | also fair.... hmm |
| 14:09 | <James M Snell> | from prior art, it's worth noting that in Node.js Buffer, they overload indexOf/lastIndexOf for this.. e.g. Buffer.from('hellohello').lastIndexOf('hello') === 5 |
| 14:10 | <James M Snell> | not suggesting we do the same but lastIndexOfSequence would follow that existing pattern |
| 14:15 | <nicolo-ribaudo> | We just need some parentheses -- haystack["last(IndexOfSequence)"](needle) |
| 14:16 | <James M Snell> | haystack.findTheLastOccurrenceOfThisSequence(needle) ;-) |
| 14:25 | <Michael Ficarra> | @sffc Correct, the entirety of the proposal aside from syntax can be implemented in a polyfill. |
| 14:33 | <Justin Ridgewell> | What happened to the room? |
| 14:33 | <Justin Ridgewell> | No audio no video |
| 14:35 | <Rob Palmer> | really |
| 14:35 | <Elliot Goodrich> | All good |
| 14:35 | <Justin Ridgewell> | It came back |
| 14:38 | <Michael Ficarra> | this seems like a good topic for TG5 |
| 14:41 | <Michael Ficarra> | don't tempt me |
| 14:41 | <Michael Ficarra> | I looooove long descriptive method names and variable names |
| 14:53 | <James M Snell> | heh.. ok, it does seem we have disagreement on this tho that we may need to get broader opinion on... the options it seems are either one of (a) lastIndexOfSequence or (b) indexOfLastSequence. Curious what others beyond Michael Ficarra and bakkot feel is the better / less ambiguous / less confusion choice |
| 14:56 | <James M Snell> | while folks are considering that... for TypedArray concat naming... I'm thinking of going with %TypeArray%.fromList([...]), ArrayBuffer.fromList([...]), and SharedArrayBuffer.fromList([...]) since concat appears to not be workable |
| 14:57 | <ptomato> | yeah that's the same reasoning I've heard for why people don't like spies, and I came to a similar conclusion 😄 |
| 14:58 | <peetk> | objectively (a) is ambiguous and (b) is not, although the degree to which the average developer is vulnerable to the ambiguity in (a) is an empirical question |
| 14:59 | <peetk> | maybe locateSequence and locateLastSequence avoids the issue? |
| 15:01 | <nicolo-ribaudo> | subsequentceIndex / subsequenceLastIndex? |
| 15:01 | <nicolo-ribaudo> | Ok no it's ambiguous |
| 15:01 | <nicolo-ribaudo> | lastSubsequenceIndex |
| 15:02 | <James M Snell> | I do think it's likely better to keep a name that is closely similar to indexOf |
| 15:04 | <peetk> | then i would vote indexOfLastSequence |
| 15:09 | <bakkot> | please no. we have lastIndexOf already! |
| 15:10 | <bakkot> | indexOf / lastIndexOf // indexOfSequence / indexOfLastSequence? no! no!!!! |
| 15:11 | <Olivier Flückiger> | It's common that for performance critical operations we'll have different implementations and fast-paths in builtins depending e.g. on input types and so on. |
| 15:11 | <Olivier Flückiger> | That's before we would hit any kind of optimizing compiler, which is yet another story... |
| 15:11 | <peetk> | thousands would die!! |
| 15:12 | <bakkot> | thousands would correctly be mad at us anyway |
| 15:12 | <peetk> | consistency is good but avoiding ambiguity seems more important |
| 15:12 | <Michael Ficarra> | @Richard Gibson The thing I was going to say is that this seems like a good research project. If we could teach esmeta how to set up initial conditions sufficient for reaching all paths taken through each AO, I think it could be made to auto-generate tests that are "exhaustive" in this way. We should talk to the esmeta people about it. Do you want to come to a TG5 meeting? /cc @Mikhail Barash @Jihyeok Park |
| 15:13 | <bakkot> | given the consistency there is no ambiguity |
| 15:13 | <Richard Gibson> | yes, that sounds great! |
| 15:13 | <bakkot> | also, no, consistency can be more important even then |
| 15:13 | <Olivier Flückiger> | ⬆️ Richard Gibson |
| 15:15 | <peetk> | well certainly no ambiguity for ecma-262 editors |
| 15:15 | <peetk> | can you elaborate on this |
| 15:18 | <bakkot> |
(sorry, moving out of thread because threads have a painful UI) ambiguity bites the first time you read it, but it's relatively easy to internalize. whereas inconsistency bites every single time because it is much harder to learn/remember an inconsistency |
| 15:18 | <Ashley Claymore> | fwiw I am +1 for checking in generated test cases. Instead of the fully runtime based harness. |
| 15:24 | <peetk> | i guess what i have in mind is a developer who uses this method extremely infrequently, and thus does not remember how the ambiguity resolved last time, but does have autocomplete in vscode. maybe if we're optimizing for power users the calculation is different |
| 15:24 | <bakkot> | I'm imaging readers, not writers |
| 15:25 | <bakkot> | for a reader, seeing indexOfLastSequence looks like a bug every time |
| 15:25 | <Jihyeok Park> | That sounds like a great direction! I'd be happy to join the TG5 meeting to discuss how we can bridge this research into a practical contribution for Test262. |
| 15:26 | <James M Snell> | I'm kind of leaning that way also. the more I look at it, the asymmetry between indexOf/indexOfSequence then lastIndexOf/indexOfLastSequence just feels very awkward |
| 15:27 | <peetk> | i do not share this intuition |
| 15:33 | <bakkot> | also |
| 15:33 | <bakkot> | we already have String.prototype.lastIndexOf |
| 15:33 | <bakkot> | which takes a string |
| 15:33 | <bakkot> | and returns the first index of the last occurence |
| 15:33 | <bakkot> | it is exactly this method |
| 15:34 | <rbuckton> | If I am reading these in english, I think indexOfSequence is "Give me the index of this sequence", and lastIndexOfSequence means "Give me the last index of this sequence". indexOfLastSequence reads as "Give me the index of the last sequence" |
| 15:35 | <Richard Gibson> | if the name alignment is going to drift a bit anyway, that opens up room for things like indexOfChunk/indexOfChunkFromEnd |
| 15:36 | <Richard Gibson> | s/Chunk/Sequence/ to taste |
| 15:36 | <Michael Ficarra> | please don't use the word "chunk", I don't want to compromise the iterator helper methods |
| 15:38 | <bakkot> | go has lastIndex taking a sequence https://pkg.go.dev/bytes#LastIndex |
| 15:38 | <bakkot> | java has lastIndexOfSubList taking a list https://docs.oracle.com/javase/8/docs/api/java/util/Collections.html#lastIndexOfSubList-java.util.List-java.util.List- |
| 15:39 | <Dmitry Makhnev> | Regarding the question about the distance between Amsterdam and TU Delft: Google Maps says it takes approximately 1 hour 18–21 minutes: https://maps.app.goo.gl/rGzzqN5edC4AbfHB6 We’re going to organize direct bus transfers from the JetBrains office to TU Delft and back. However, I’m planning to invite anyone interested to join a walk around Delft after TG5, to explore the city a bit more. Delft is really beautiful. |
| 15:40 | <bakkot> | C# also has lastIndexOf https://learn.microsoft.com/en-us/dotnet/api/system.memoryextensions.lastindexof?view=net-10.0#system-memoryextensions-lastindexof-1(system-readonlyspan((-0))-system-readonlyspan((-0))) |
| 15:43 | <peetk> | then i guess i prefer indexOf/lastIndexOf but i guess we've been over that already |
| 15:44 | <James M Snell> | So many possible colors for the bikeshed and all slightly the wrong hue |
| 15:45 | <James M Snell> | Actually... Michael Ficarra just pointed out that if we follow the precedent we just established with TypedArray concat with dropping Iterables from consideration... we probably could just go ahead and update indexOf/lastIndexOf to support sequences also and we don't have to worry about the naming of a new function... |
| 15:45 | <bakkot> | scala has lastIndexOfSlice https://www.scala-lang.org/api/2.13.1/scala/collection/IndexedSeqView$$Slice.html#lastIndexOfSliceB%3E:A:Int |
| 15:46 | <bakkot> | what other languages even are there |
| 15:46 | <bakkot> | smalltalk has indexOfSubCollection |
| 15:46 | <bakkot> | but not last, I guess |
| 15:48 | <Richard Gibson> | I don't think so, this naming concern is based upon shape more generally—accepting a sequence of potentially multiple elements (however specified) rather than just a single element |
| 15:49 | <rbuckton> | I'd like to avoid using Slice as I still have hopes of us at some point having a form of Slice literal notation (x:y) to go with the array slice proposal a[x:y] |
| 15:49 | <peetk> | I think it was just intended as support for lastIndexOfX generally |
| 15:49 | <Michael Ficarra> | Can you clarify? I don't get this. |
| 15:49 | <bakkot> | even if we don't drop iterables, I think? I don't think dropping iterables actually affects anything here, since TA indexOf uses strict comparison and does not coerce (and we agreed never to treat primitives as iterables) |
| 15:50 | <Michael Ficarra> | no, only if we drop iterables/array-likes |
| 15:50 | <rbuckton> | IMO, lastIndexOfSequence is fine in a world where we have editors with autocomplete. |
| 15:50 | <bakkot> | why? |
| 15:50 | <Richard Gibson> | even with argument restriction to match the type of receiver, I'd still want a name that is not indexOf |
| 15:51 | <bakkot> | I'm imagining the branch being, argument is primitive -> current algorithm, is TA-> TA algorithm, is other object -> iterable algorithm |
| 15:52 | <rbuckton> | indexOfX implies getting the index of whatever X is. I don't see why we wouldn't want to use that. |
| 15:53 | <bakkot> | I can't tell if this is an argument for overloading indexOf(sequence) or having a separate indexOfSequence(sequence) |
| 15:53 | <rbuckton> | It's neither? It's an argument against choosing "a name that is not indexOf" |
| 15:54 | <Aki> | This has been a pet issue of mine for 20 years and I'm just delighted that someone is presenting on it |
| 15:54 | <rbuckton> | Unless that argument was specifically about not overloading indexOf, in which case I apologize for the misunderstanding |
| 15:55 | <Michael Ficarra> | is this because you don't like the overload between a number and a TA? |
| 15:55 | <Richard Gibson> | indexOf 👎️ indexOf$Noun 👍️ lastIndexOf$Noun 🆗 |
| 15:56 | <Michael Ficarra> | @Richard Gibson I want to understand your 👎️ |
| 15:56 | <Richard Gibson> | yes, but not just that... I don't like the overload between "single element" and "sequence of elements" |
| 15:56 | <rbuckton> | I don't have a strong preference for or against overloading indexOf, given that String sort of sets a precedent, even if it's very narrow. |
| 15:57 | <Richard Gibson> | String.prototype.indexOf accepts only a sequence, while Array.prototype.indexOf accepts only a single element |
| 15:58 | <Michael Ficarra> | no it doesn't, Strings are self-recursive structures |
| 15:58 | <rbuckton> | That's why I said "very narrow". You have to squint a bit. |
| 15:58 | <Richard Gibson> | we're saying the same thing? |
| 15:59 | <rbuckton> | C#'s precedent for String is that it supports string or char: https://learn.microsoft.com/en-us/dotnet/api/system.string.indexof?view=net-10.0, so it's not unheard of in other languages. |
| 16:00 | <bakkot> | also for its generic span type |
| 16:00 | <Richard Gibson> | sure, but JS doesn't have the latter so 🤷 |
| 16:01 | <Michael Ficarra> | oddly, this is more compelling precedent to me than JS's own String.prototype.indexOf |
| 16:01 | <bakkot> | C# has both LastIndexOf<T>(Span<T>, ReadOnlySpan<T>) and LastIndexOf<T>(Span<T>, T) |
| 16:01 | <rbuckton> | My point is that I don't believe users would be confused by the overload. |
| 16:01 | <Michael Ficarra> | it means users will get it, even when working with a good type system |
| 16:02 | <bakkot> | (to be clear I am ~neutral between overloading indexOf vs having a separate indexOfSequence, I think they're both totally fine) |
| 16:02 | <rbuckton> | Java's String also overloads indexOf for string and char (well, int, but same purpose) |
| 16:02 | <Richard Gibson> | overloading makes more sense with a good type system, not less |
| 16:04 | <rbuckton> | Go does not, but Go also doesn't really support overloads (aside from generics) |
| 16:05 | <Michael Ficarra> | I think we need to remind people that "clarifying question" is not "new topic that can be phrased as a question" |
| 16:05 | <Michael Ficarra> | it's been misused a couple times this meeting |
| 16:06 | <Ashley Claymore> | maybe "clarification required" |
| 16:08 | <Michael Ficarra> | the "I promise I am going to ask the speaker to clarify something that they've already said because I didn't understand it" button |
| 16:09 | <Michael Ficarra> | btw I don't buy the claim that they were able to measure post-interaction dead code synthetically |
| 16:10 | <Michael Ficarra> | "I had a bot click on everything" is just not sufficient methodology |
| 16:11 | <bakkot> | I wish we tried harder to make good minifiers, it's not actually hard to do better than we're doing |
| 16:12 | <Michael Ficarra> | still probably better for people to just write their code for DCE |
| 16:12 | <Ashley Claymore> | The issue I've had with minifiers is that the primary goal is "smallest" rather than "correct" |
| 16:13 | <Ashley Claymore> | minifier bugs that change logic be scary |
| 16:13 | <Chengzhong Wu> | As a library author, I think a question is also "how can I deterministically verify my code can be minifed?" |
| 16:13 | <Michael Ficarra> | Spill the tea. Name some names. |
| 16:13 | <Ashley Claymore> | can spill over tea |
| 16:14 | <James M Snell> | Node.js has precedence for this overload as well, which I think is fairly more significant here |
| 16:14 | <James M Snell> | buffer.indexOf(otherBuffer) and buffer.lastIndexOf(otherBuffer) already Just Works there |
| 16:14 | <Jeff Posnick> | FYI for folks who've never seen this before: the Web Almanac is an annual project that dives into data from the HTTP Archive. They have a section dedicated to Page Weight that's very relevant to this dicussion: https://almanac.httparchive.org/en/2025/page-weight |
| 16:14 | <Michael Ficarra> | that's hugely compelling @James M Snell |
| 16:16 | <bakkot> | if people were willing to write their code in a different way in order to allow dead method removal, bundlers could implement a convention that a method prefixed with __ is pinky-promised to only be invoked literally, so that __foo can safely be removed if __foo() never appears |
| 16:16 | <bakkot> | that this has not happened makes me somewhat skeptical of proposals of the form "let's give people a new way to write methods so they get DCE'd" |
| 16:17 | <Ashley Claymore> | bundler convention = vendor lock in |
| 16:17 | <Ashley Claymore> | standard = maybe better |
| 16:18 | <bakkot> | still would like an answer to this |
| 16:19 | <bakkot> | fair, though I think bundlers would probably be willing to collaborate on these things |
| 16:19 | <bakkot> | and/or copy each other |
| 16:19 | <Michael Ficarra> | it's a lot easier to explain that overload IMO |
| 16:19 | <bakkot> | ... how so? |
| 16:20 | <bakkot> | value vs sequence is the natural way of thinking of it |
| 16:20 | <bakkot> | and that's the overload proposed |
| 16:22 | <ljharb> | rollup broke airbnb for IE 11 users in 2018 for like 3 months because one of its heuristics is "if it throws it can be deleted", which is false |
| 16:23 | <bakkot> | I'm sure both of them were very sad |
| 16:23 | <ljharb> | lol |
| 16:23 | <bakkot> | (this is a joke, I agree that's bad) |
| 16:23 | <Michael Ficarra> | if it was broken for 3 months, both IE11 users probably weren't using airbnb |
| 16:23 | <bakkot> | not by the end of those months I'm sure! |
| 16:24 | <Michael Ficarra> | easy solution for raising min browser support: drive away all your users who use old browsers |
| 16:28 | <ljharb> | we did the math and it was a meaningful revenue loss ¯\_(ツ)_/¯ rollup fixed it by accounting for the es5-shim and es6-shim patterns specifically, rather than just removing the heuristic |
| 16:28 | <Ashley Claymore> | Actual "private symbols": https://github.com/tc39/proposal-private-declarations |
| 16:30 | <bakkot> | I want to bring that proposal back |
| 16:30 | <bakkot> | think it will be my next thing after async iterator helpers |
| 16:30 | <bakkot> | if no one else does it |
| 16:30 | <bakkot> | I do wish we'd required private #x in classes so we could have a clean way of referring to names declared outside a class, but alas |
| 16:31 | <bakkot> | (as it is, we're stuck with like class { [#x] = foo } or class { outer #x = foo } or something) |
| 16:34 | <nicolo-ribaudo> | Those proposals should probably start taking into account optional chaining too |
| 16:34 | <nicolo-ribaudo> | Since that's a nice benefit we currently get from property access |
| 16:40 | <Ashley Claymore> | I do want 'optional pipeline chain' |
| 16:40 | <Ashley Claymore> | (assuming we had pipeline) |
| 16:41 | <nicolo-ribaudo> | I like classes though, they are the most ergonomic way for private state |
| 16:41 | <nicolo-ribaudo> | I wouldn't want to consider them "deprecated"/"bad" as an official position |
| 16:42 | <ljharb> | closed-over variables are pretty ergonomic, but private symbols would be nicer |
| 16:42 | <bakkot> | I assume the goal is private per-object state but shared methods |
| 16:43 | <Michael Ficarra> | who is speaking? |
| 16:43 | <peetk> | steve from cloudflare |
| 16:43 | <Michael Ficarra> | is that Steve's last name? |
| 16:43 | <ljharb> | only my father calls me Mr. From Cloudflare |
| 16:43 | <peetk> | faulkner |
| 16:44 | <Michael Ficarra> | Steve Faulkner (SFR)? |
| 16:44 | <Michael Ficarra> | okay thank you |
| 16:45 | <Rob Palmer> | We had bundler folk attend the November 2025 meeting in Tokyo. Saphi-Red and Chris Nazakawa from VoidZero. |
| 16:45 | <jschoi> | The pipe operator proposal, for what it’s worth, already has a section devoted to ?|> or |?> as a follow-up proposal. (Which could be extended to arbitrary functors, monads, etc., but let’s not go there……) |
| 16:54 | <nicolo-ribaudo> | bakkot Do you think Uint8Array is rare too? |
| 16:54 | <nicolo-ribaudo> | There are multiple common web APIs that produce it |
| 16:54 | <bakkot> | relatively speaking, yes, though getting less so |
| 16:54 | <nicolo-ribaudo> | I agree that all others are very rare |
| 16:54 | <bakkot> | I think TextEncoder is the only really common one |
| 16:55 | <Michael Ficarra> | can people online hear Rob? |
| 16:56 | <bakkot> | yes |
| 16:57 | <Michael Ficarra> | I am sure @saminahusain would prefer they just become a member though |
| 16:57 | <Michael Ficarra> | I hear Ecma's pretty desperate for new members |
| 16:59 | <saminahusain> | Desperate is a strong word...but would be happy to have new Ecma members. 👍️ |
| 17:43 | <bakkot> | chairs: could we get 3 minutes for a continuation for iterator includes? we can take it out of my time slot |
| 17:44 | <bakkot> | re https://github.com/tc39/proposal-iterator-includes/pull/8 if anyone's curious |
| 18:05 | <Rob Palmer> | sure - we'll schedule it after your iterator includes, so it will be your responsibility to end it early enough. 4pm is a hard cut-off. |
| 18:06 | <Rob Palmer> | I assume you will not be asking for stage advancement in 3 mins |
| 18:07 | <bakkot> | it already got stage advancement, this is a bugfix for the spec text we just approved |
| 18:29 | <bakkot> | I still think we should make Object.prototype exotically reject "then" |
| 18:44 | <dminor> | Fwiw, I've been uncomfortable with these rapid advancements to Stage 2.7 for a while, and I think this is evidence that we should take things more slowly. Not that this was a big deal to fix, but I don't see what we're gaining by going as quickly as possible. |
| 18:44 | <bakkot> | a fair concern but fwiw I don't think waiting would have helped at all with this |
| 18:45 | <bakkot> | we've made the same mistake with slower ones |
| 18:45 | <ljharb> | ftr i didn't even catch it when implementing it |
| 19:10 | <Michael Ficarra> | yeah I really don't think pace had anything to do with it |
| 19:10 | <Michael Ficarra> | if we wanted to make it less likely to happen, we could insist on more eyes on reviews, but I think 2 reviewers strikes a good balance |
| 19:19 | <Michael Ficarra> | what about that callback keeps everything in the function alive? |
| 19:20 | <Michael Ficarra> | there's no direct eval |
| 19:20 | <Chengzhong Wu> | ecma262 callback does not require keeping everything in the function alive, technically |
| 19:21 | <ljharb> | it should only be keeping promise alive, i'd expect |
| 19:22 | <Michael Ficarra> | yeah same |
| 19:26 | <Lea Verou> | Or preventExtensions altogether: https://es.discourse.group/t/automatic-preventextensions-on-object-prototype/2516 |
| 19:27 | <rbuckton> | Could leverage AsyncContext.Variable for this. I just threw together a rough implementation using AsyncContext and AbortController that looks something like this:
|
| 19:32 | <rbuckton> | That said, I'm not a huge fan of a general purpose "ambient AbortSignal" approach |
| 19:33 | <Chengzhong Wu> | would you count this Scope as "ambient AbortSignal" if it has the "DOM extension" as in the snippet above? |
| 19:34 | <Chengzhong Wu> | or are you referring to sth like AbortSignal.current? |
| 19:36 | <rbuckton> | This is less bad than an ambient cancellation approach that just magically cancels things, so its slightly more palatable |
| 19:37 | <Ashley Claymore> | https://www.youtube.com/watch?v=h1GvSPaRQ-U&; |
| 19:49 | <rbuckton> | A class that affords for explicit passing of a signal and collecting the waiting promises to await Promise.allSettled during cleanup might be interesting. |
| 19:58 | <rbuckton> | No AsyncContext, just
|
| 19:58 | <Evan Winslow> | Yea, this is very fair. Best I can really say is "I have not yet been able to figure out how to execute this code" rather than "we have definitively confirmed this code is unreachable by any sequence of interactions". |
| 20:34 | <bakkot> | it doesn't have to, it's just that it does in practice; engines capture at granularity of whole scopes, not individual variables |
| 20:39 | <bakkot> | I had something like this originally but I ended up thinking it was nicer for the functions to register themselves on the signal instead of the caller needing to wrap every function call |
| 20:41 | <bakkot> | could go either way though |
| 21:21 | <bakkot> | transcription service cost $1.88 |
| 21:22 | <ljharb> | it doesn't have to, it's just that it does in practice; engines capture at granularity of whole scopes, not individual variables |
| 21:22 | <bakkot> | I'm not going to invoice ecma for that although if they want to give me the money which was going to pay for other people to do the transcript, I wouldn't be opposed |
| 21:26 | <rbuckton> | I had something like this originally but I ended up thinking it was nicer for the functions to register themselves on the signal instead of the caller needing to wrap every function call |
| 21:33 | <iain> | re engines capturing scopes: I don't know what the original example was, but in practice the way it works is that you hold onto the entire closure if anything is using it, even if individual variables in the closure are no longer reachable. So if you have function foo() { let a = {}; let b = {}; return [() => a, () => b]} then the arrow functions will each keep both a and b alive, despite only technically needing one of them. The technical term here is "safe for space". All three engines have long-standing bugs open to fix this (sm, v8, jsc), but it's hard to get right. It would effectively require us to track that a closure is only partially alive, which is not how the GC normally works, and there's lots of fiddly little cases. |
| 21:35 | <iain> | Note that variables are only captured in the closure if they're used in an inner function, so if you had a separate let c = {} in my example without a corresponding arrow function, it would not be kept alive. |
| 21:47 | <Ashley Claymore> | transcription service cost $1.88 the quality was great IMO |
| 21:55 | <mgaudet> | It was definitely 1.88$ worth of money |
| 21:58 | <mgaudet> | (If anyone has opinions on how to opt into the 'deferred/safe' resolve semantics, I did find something which means we'd probably need to be tight on coercion for the second argument to the resolve function: https://github.com/tc39/proposal-thenable-curtailment/issues/9 |
| 21:58 | <mgaudet> | but with that I run away for EOD, enjoy y'alls evening in NY |