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...

haystack.indexOfSequence(needle, -10);  // search forward from 10 elements from the end, etc
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>

can you elaborate on this

(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:

declare class Scope {
    [Symbol.asyncDispose](): Promise<void>;
    fork<R>(cb: () => R): Promise<R>;
    static get hasExited(): boolean;

    // DOM extension?
    // static get signal(): AbortSignal;
}

async function f() {
    await using scope = new Scope();
    const a = scope.fork(async () => { ... if (Scope.hasExited) return; ... });
    const b = scope.fork(async () => {});
    const c = scope.fork(async () => {});
    const [aa, bb, cc] = await Promise.all([a, b, c]);
}
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 Promise enlistment tracking and a cleanup callback:

const controller = new AbortController();
const { signal } = controller;

await using scope = new Scope(() => controller.abort());
const [a, b, c] = await Promise.all([
  scope.enlist(fetchUser(userId, { signal })),
  scope.enlist(fetchOrders(userId, { signal })),
  scope.enlist(fetchRecommendations(userId, { signal }))
]);
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
that is very surprising - it seems like in the “no direct eval, no with” cases you could just only hold on to every mentioned identifier in the closure. Why is that difficult to do? (genuine question since i don’t have engine impl experience)
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
Unfortunately, registering on the signal doesn't help with awaiting all of the cleanup from those tasks
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
Wow! That's much less than I was expecting.
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