Justin Ridgewell: I am also happy to review ye olde dedente

also RTX Voice from nvidia: https://www.nvidia.com/en-us/geforce/guides/nvidia-rtx-voice-setup-guide/

wait, this creates a visible private field whose name is derived from the name of the accessor? i thought decorator's auto-accessors created private fields which you couldn't actually refer to (even in the body of the class)

would people be opposed to moving to zoom? IME it's the highest A/V quality and most reliable among the video conference apps. would a member company be willing to always host zooms?

bakkot, ljharb: I'm fine with stage 2 for duplicate named capture groups. The remaining discussion issue is the property creation order issue. I'd prefer the order to be fixed for a given regexp, not variable from invocation to invocation. Looks like some of you agree?

bakkot, ljharb: I'm fine with stage 2 for duplicate named capture groups. The remaining discussion issue is the property creation order issue. I'd prefer the order to be fixed for a given regexp, not variable from invocation to invocation. Looks like some of you agree?

(actually I kind of want a WeakMap.clone)

(don't post the URL here - I will put it on the Reflector

(don't post the URL here - I will put it on the Reflector

Temporal would need to depend on DurationFormat for Duration#toLocaleString anyway

rather, it can just be, "hey, we delimited this subset. Implementers, does this seem good to ship separately, before that other part is done?"

I have to ask this every time, but: what was the reasoning behind generators stopping immediately when invoked instead of running until first yield?

I have to ask this every time, but: what was the reasoning behind generators stopping immediately when invoked instead of running until first yield?

it can be good to coordinate expectations about this subset, but I don't think this requires making a new repo, seeking consensus on advancement, etc

oh okay yeah I think that was the motivation: you either miss the first next-ed value or you miss the first yield-ed value

oh okay yeah I think that was the motivation: you either miss the first next-ed value or you miss the first yield-ed value

well this function.sent proposal is from the same era, so I'm guessing that delegates at the time just assumed we would add something along these lines to fix this problem

the ~2 times this has ever come up for me I just said that you had to prime the generator with a throwaway call to .next(). any time you're passing stuff into the generator you're defining a new protocol anyway (the iterator protocol doesn't pass anything), so it's not so burdensome to make that be a part of the protocol.

bakkot: can't you just expose a wrapper that does the priming instead?

Something like generatorWithContext(function * (context, x, y) { console.log(context.sent) }) where generatorWithContext injects a { sent } context object in the first parameter would work too.

oh, static methods with this is a bit weird? to me?

an interesting case would be:

function f(this?: T | null) {}

yes that seems to very much work against the "narrow TS gap" motivation

Yikes! Now we'd be introducing the concept of a function that can't ever be faithfully called via Function.prototype.call.

for TS side it's easy, just add a emitThisParameter like what they did to the class fields

Note, the change in class fields emit is an ongoing disaster for us

it won't be so disaster like class fields

because they both have runtime semantics and they're different

in this case, only ES version has RS and TS version don't

This would introduce a runtime semantic that is in conflict with TS, so if there's a --emitThisParameter TS would need a different way to indicate a disallowed this or optional this, so its not quite as simple.

I think out-of-bound declaration files from Definitely Typed could become misleading at the least which is undesirable. Your build won't be broken, but the actual problem is the runtime behavior change which is generally seen as worse because there's no way to signal to a user "hey, this is now different"

If a method expects this in .d.ts and you don't provide it, TS already report type error

The specific case in mind is the optional this. e.g.

function foo(this: Foo | undefined, ...args: any[]): void