Apply suggestions from code review

Co-authored-by: Chris de Almeida <ctcpip@users.noreply.github.com>
Co-authored-by: Daniel Ehrenberg <dehrenberg@bloomberg.net>

meetings/2024-07/july-29.md

@@ -245,9 +245,9 @@ Presenter: Chris de Almeida (CDA)
 - no proposal
 - no slides
 
-CDA: The conduct goes well for the most part. We have not had any new reports and nothing notable in our spaces and disasters course or GetHub.
+CDA: The conduct goes well for the most part. We have not had any new reports and nothing notable in our spaces and discourse or GitHub.
 
-CDA: We have not – we prefer not to be busy on the Code of Conduct committee, as always, I will repeat my pitch for folks who would like to join the Code of Conduct committee and please reach out to one of on the Code of Conduct committee and the main and is that you are available for period of one hour every two weeks. Often we do not have to meet during that hour because we have nothing to talk about but it is important that it is blocked out on your calendar to we can function as a committee when we need to. So thank you.
+CDA: We have not – we prefer not to be busy on the Code of Conduct committee, as always, I will repeat my pitch for folks who would like to join the Code of Conduct committee and please reach out to one of us on the Code of Conduct committee. The main ask is that you are available for a period of one hour every two weeks. Often we do not have to meet during that hour because we have nothing to talk about but it is important that it is blocked out on your calendar so we can function as a committee when we need to. So thank you.
 
 RPR: all right thanks Chris. We have a cool collection there for anyone who wants to be a volunteer. And please consider it. Next up, we have – I clicked the button. Ben Allen with Intl.DurationFormat display negative sign on
 
@@ -707,7 +707,7 @@ SYG: I don’t know how to make progress from here because we’re debating on s
 
 USA: Thank you, Shu. So I think we could capture the queue from today and come back to this.
 
-DE: so as part of the conclusion say people disagree with this as implementation defined engage before the next meeting? This is a request from SYG and this included WH and maybe other people on the queue and MLS.
+DE: Can we agree, as part of the conclusion, that people who disagree with calling the behavior "implementation-defined" will engage with SYG offline before the next meeting? e.g., WH, MLS.
 
 USA: Shu, did you agree with the conclusion?
 
@@ -953,7 +953,15 @@ MF: Sure. Sure I will write it in the notes.
 
 CZW: All right, I will share my screen. It is black for me, I don’t know.
 
-ABO: This is Andreu, and so this the AsyncContext update about integration, and some – next slide.DE: If I can jump in, I got in touch with some framework feedback about AsyncContext, and people are generally very excited about this feature, and both for client and server and so discussed some Dev’s, and keeping track of what the component is as well as performance tracing and I had some hopes that AsyncContext would make sense for abrupt context file variables but these are already handled very well by referencing the tree, there is a lot of demand for that in particular. But I think it is safe to say this feature would be to positive effects for allowing adoption of async await frameworks.
+ABO: This is Andreu, and so this the AsyncContext update about integration, and some – next slide.
+
+DE: If I can jump in, I got in touch with some framework maintainers about AsyncContext, and people are generally very excited about this feature, and both for client and server. Some use cases include
+- keeping track of what the component is
+- performance tracing
+- maintaining hooks state
+- Generally, allowing adoption of async/await in frameworks
+
+I had some hopes that AsyncContext would make sense for the equivalent of React Context, but these are already implemented efficiently by referencing the component tree, so there is not a lot of demand for that particular usage mode.
 
 CZW: We also – next slide please. So we designed syntax API and use case and this is a [INDISCERNIBLE]. So, this is start of API which is using stable subset and this stable subset is about AsyncContext. And open tell met tree and so with this part of syntax, we can have the benefit of that storing global variables because in the lab and also have the support of –
 
@@ -975,11 +983,17 @@ DE: Can I address here your question Mark, and I am on the queue?
 
 MM: Please.
 
-DE: So, yes, for promises, promise end is consistently handled as well as promise catch, there consistently handles with in the context snapshot where the reaction was scheduled. So whether you do a weight or you do then or catch or finally, it is always withdrawing that same one. Now our behaviour with callback in the web platform is to basically do that as well. Just as easily as promises, they restore that snapshot. Sometimes there is other contextual information that is relevant. And so, the solution we are going for and rather than doing something fancy and automatic is to make it so that it is as if you constructed a new AsyncContext snapshot at the point when some interesting thing happened. So in this case, it is for – when you reject a promise, the snapshot is sort of eagerly captured. And then if it turns out it is not handled, then um, then that will get passed to the event. An alternative semantics when promise is allocated and capture snapshot in case it is an unhandled rejection. These two sound different but turns out that they are actually similar. And we were not really able to find that cases that one behaved differently than the other for developers and we are proposing where it is at the time of rejection. Though for example the system then, a promise you know and there is no JavaScript when it is rejected, and then it has to have been captured earlier. For example when the promise is allocated.
+DE: So, yes, for promises, `Promise.then` is consistently handled as well as `Promise.catch`: both reactions consistently run within the context snapshot where the reaction was scheduled. So whether you do `await` or you do `.then` or `.catch` or `.finally`, it is always executing within that "registration" context.
+
+DE: Now, our proposed behaviour with callbacks in the web platform is to basically do that as well. Just like Promises, they restore the context snapshot which was active when the callback was received as an argument. Sometimes there is other contextual information that is relevant. And so, the solution we are going for and rather than doing something fancy and automatic is to make it so that it is as if you constructed a new AsyncContext.Snapshot at the point when some interesting thing happened, and that is made available somewhere else for explicit use.
+
+DE: For example, when you reject a promise, the snapshot is sort of eagerly captured. And then if it turns out it is not handled, then that snapshot will get passed to the event handler, exposed as a property on the Event object.
+
+DE: An alternative semantic is, when promise is allocated and capture snapshot in case it is an unhandled rejection. These two sound different but turns out that they are actually similar. And we were not really able to find that cases that one behaved differently than the other for developers and we are proposing where it is at the time of rejection. Note that, when the platform has an API which returns a Promise, there might be no JavaScript active when the Promise is rejected, and so the platform must cache the Snapshot earlier, e.g., when the Promise is allocated.
 
 MM: You should note by the way the idea of capturing these is attractive to me. I like the idea of it. I am just – what I am raising is how it fits with the rest of the SA men ticks and you answered that very well, and I will clarify two things. And that it is only – if you are capturing the rejection, it is only want rejection, and not on fulfillment.
 
-DE: That is right. The argument is that we do this on fulfillment as well and that is not currently being proposed, what is being proposed is unfulfillment and nothing is captured.
+DE: That is right. Our proposal is that, on fulfillment, nothing is captured.
 
 ABO: It should be noted that this is 100% in the host like inside of the host. And when a promise is rejected, it will call the promise rejection host at that time like if you call the reject handler, and at that reject function. At that time synchronously the host will get called and it is the host that stores that and eventually fires the 100 rejection event. And so it is the host who is taking it is snapshot and saving it somewhere.
 
@@ -1033,7 +1047,7 @@ DE: Yeah you are right, thank you for the correction. So, are there any particul
 
 KKL: I want to – I am on the queue. In the previous life I was involved in the open context project, and precursor to open tel., and so this comes to propagation that will come to bear on this, and this is interesting because reverse context propagation reverses the arrow in the way that goes from one to many to many to one. Which sometimes implies that you have to use completely different data structures to pull data out of reverse context. I don’t know whether this comes to bear on this, and really just wanted to propose that we talk through it on TG3, and if you can add yourself to a future agenda that would be great. The thing about reverse context that happens if you fanout to multiple parties and any of them might return reverse context is that the return context has to be aggregated some way in order to be made sense of at the conception site. So get – the get on the last line of this example would effectively require a reduction of possibly many changes. And in any case, again I don’t know whether that comes to bear, but it would be great to talk through.
 
-DE: Yeah, we have had a bit of debate about this within the group, and I agree that there are some multiple context that are relevant. Which is kind of why we would hoping to go with this simple policy. But yeah, let’s get on the TG3 ideas.
+DE: Yeah, we have had a bit of debate about this within the group, and I agree that there are some multiple context that are relevant. Which is kind of why we would hoping to go with this simple policy. But yeah, let’s get on the TG3 agenda.
 
 CZW: Yes thank you and that sounds good, and as I want to point out too that merging is also mentioned in the document in 94, and we have been discussing it what the possible ways to merge multiple context in this context to one final value. So yeah, I think it would be valuable to the idea TG3 general.
 

meetings/2024-07/july-30.md

@@ -351,7 +351,7 @@ DLM: It’s just the principle. ABL has been doing a huge amount of work to get
 
 SYG: Thanks
 
-DE: I apologize for muddying the waters a bit by voicing support for this in the chat. When the coercion topic came up, this is one of my original concerns that we not apply it to Stage 3 proposals. If it were possible to do this very cheaply, I think it would be nice. But I guess the—I would really want to conclude today on in principle whether we’re making this change. If we don’t conclude today we’re making this change, we’re not doing it for Temporal because as pFC said, it’s already shippable. The work that PFC did that went into the removal was kind of more significant than initially expected. I think he could tell it was going to be a lot of work. But there are just a lot of places where coercion happens. It wouldn’t be realistic.
+DE: I apologize for muddying the waters a bit by voicing support for removing coercion in Temporal in the Matrix chat. When the coercion topic came up, this is one of my original concerns that we not apply it to Stage 3 proposals. If it were possible to do this very cheaply, I think it would be nice. But I guess the—I would really want to conclude today on in principle whether we’re making this change. If we don’t conclude today we’re making this change, we’re not doing it for Temporal because as PFC said, it’s already shippable. The work that PFC did that went into the removal was kind of more significant than initially expected. I think he could tell it was going to be a lot of work. But there are just a lot of places where coercion happens. It wouldn’t be realistic.
 
 PFC: In particular, I think it would invalidate a lot of the Test262 tests that we have. I mean, it might reduce their number which would be nice. But it would be a non-trivial amount of work.
 
@@ -450,7 +450,7 @@ MM: Okay. You have some support. Chris Cole says I like `iterator.zip` and itera
 
 CDA: Any objections?
 
-CDA: You have another +1 for zipkeyed and different keys from JSON. Now that I’m reading it there’s no end of message there. Did you want to speak?
+CDA: You have another +1 for zipkeyed from JWS. Now that I’m reading it there’s no end of message there. Did you want to speak?
 
 JWS: No. That was it.
 
@@ -527,7 +527,7 @@ DE: I think the plan is we will pick this up again, right?
 
 NRO: Yes.
 
-DE: Some interesting feedback from the committee would be if people feel like the way that we were previously going of using this kind of lexical name space but statically was acceptable. So if you have opinions about that, either shut them out now or come to some of the modules calls that we have on the TC39 calendar. I would like to go the way that was previously proposed where we—which NRO has fully written out a good specification for where it’s modules are lexically scoped variables but they’re available kind of at static semantics time the way that, you know, your let declarations are checked for duplicates.
+DE: Some interesting feedback from the committee would be if people feel like the way that we were previously going of using this kind of lexical name space but statically was acceptable. So if you have opinions about that, either shout them out now or come to some of the modules calls that we have on the TC39 calendar. I would like to go the way that was previously proposed where we—which NRO has fully written out a good specification for where it’s modules are lexically scoped variables but they’re available kind of at static semantics time the way that, you know, your let declarations are checked for duplicates.
 
 NRO: And if anybody wants to join the module summary meeting, please in advance. We can make sure that all interested people are available in the meeting.
 
@@ -593,37 +593,21 @@ JHD: Yes it is. But renamed.
 
 DE: The names are kind of silly but I think this is a widely requested feature. There is a project i think in the planning stage with the University of Bergen students getting involves here, so it would be very useful to have any committee feedback on this organized for them so they can take up the proposal.. Any opinions or any cross reference to any opinions would be helpful?
 
-CDA: MF has a plus one and the one thing that we are out a Champion. And so would anyone like to take up the mantle?
-
-DE: I just mentioned there is a group that intends to take this on. Um, if you want to work with that group, then I can get you in touch.
-
-CDA: Okay.
-
-SYG: That is a bit cryptic.
-
-DE: I said the University of Bergen is trying to take this up.
-
-CDA: Oh okay.
-
-DE: So, yeah.
-
-CDA: Okay I misunderstood.
-
-DE: I’ll fix it in the notes.
+[There was confusion on whether the University of Bergen students would champion this proposal; DLM later clarified that he would work with them on championing it.]
 
 PKA: So dynamic import host adjustment, and so the Champion is KOT, not known to be active in the committee, if if anybody knows about this proposal, please share?
 
 NRO: This proposal has been transformed to a request and has had some concerns for a while. I think i might be—yes I was mistaken. I sample working with host types for a while but there is no updates on this proposal and not has been brought up with them.
 
-DE: Okay the author of this is, you know, in contact with a number of people in TC39 who are working on trusted types. So can we give some one the action to get in touch and see what everyone wants to do with this?
+DE: Okay the author of this is, you know, in contact with a number of people in TC39 who are working on Trusted Types. Can we give someone the action to get in touch and see what everyone wants to do with this?
 
 NRO: I will attend to that.
 
 DE: Thank you for much Nicolo.
 
 PKA: Okay collection normalization? Anyone has status on this proposal or have any interest on taking it out?
 
-DE: ACE actually brought up this design space in his recreation and tuples and it is linked but it can be done separately.
+DE: ACE actually brought up this design space in his Records and Tuples presentation. It is linked but it can be done separately.
 
 JHD: This is one that as I recall was almost ready to go to Stage 3, the primary objection—there has opinion a compromise reached that the primary objecter was content with but the Champion was altered(?) with the compromise and so this is one I am much more likely to take on sooner assuming that is an accurate state of affairs.
 
@@ -639,7 +623,7 @@ DE: Okay sounds good.
 
 PKA: Okay thanks I will circle back to JRL?
 
-JRL: Perfect, so I plugged in the headphones and it did not switch back to the proper mic and so intrinsic dedents and pay path length is no longer a member and just member and there is no current blockers, I just have not written the test 262 test to get this 2.7.
+JRL: About `String.dedent`: It was championed by PayPal, who is is no longer a member. There are no current blockers, I just have not written the test 262 test to get this 2.7.
 
 DE: You don't need test 262 tests for stage 2.7, you need that for stage 3. So let’s propose that for 2.7.
 
@@ -673,7 +657,7 @@ PKA: So our final item is destructuring private fields.
 
 JRL: I am no longer working on this although DE has a proposal that would assume it entirely.
 
-DE: I have a proposal that would not subsume it but make the region destructure private fields okay. This is something I have written en—I don’t have it written up in a clear way I mean, but for the old topic of private name declaration and I am wanting if we can use the syntax hash paren and expression. And instead of hash ex. This would then free up the destructure private fields syntax to what JRL proposed before and I would like to come back and present that sketch. I don’t know if I will have energy to Champion myself but given that, the destructure private fields proposal, given sort of consensus and principle at this, we can proceed with what JRL was proposing before. Do you have thoughts on this?
+DE: I have a proposal for how we could handle private name declarations, and this proposal would make it clear that the current destructuring private fields proposal is OK. It makes it clear that the syntax space used in destructuring private fields won't clash with something else. This would then free up the destructure private fields syntax to what JRL proposed before. I would like to come back and present that sketch of this alternative feature. I don’t know if I will have energy to champion the proposal myself, but if folks are convinced about the direction, then we can proceed with what JRL was proposing before. Do you have thoughts on this?
 
 PKA: Um, no that sounds good. That becomes—we just need a Champion to resume as we move forward. But that is a great update. Um, I think unless there is another comments, I think that concludes the review. Thank you everyone.
 
@@ -746,7 +730,7 @@ DE: All the API’s async, what is API are you suggesting would allow this?
 
 BAN: I am not suggesting an API and simply noting if you allow this and if you allow dynamic demonstration of locale data, you do not locate by whatever means.
 
-DE: Okay thanks for it is context.
+DE: Okay thanks for the context.
 
 BAN: It is literally this text. Saying okay, don’t do it, don’t reveal it, it is already installed with like dedictating any method of how it is not already installed or any method of not revealing that it is not already installed.