✏️ fix linebreaks

meetings/2023-05/may-15.md

@@ -41,10 +41,7 @@ USA: Next up is something very important, our IPR policy. Please remember that t
 
 CDA: Well, just a reminder on the last item that we’ve been asking folks to -- at the end of presentations to do a quick summary in the notes. That’s been very helpful. And it’s kind of on all us to remember to do that. Sometimes we forget. So please speak up, you know, use point of order if we haven’t addressed it and make sure we’re doing the end of presentation summaries.
 
-DE: I also want to note that these notes are not intended to contain personal information, and they’re available to be edited now or later in the Google Docs,
-so everyone in the committee has access to those. If you feel like a comment of yours has been inaccurately described or want to rephrase it to make it more clear, you’re really encouraged to do so.
-And further, any information deleted, you can do so yourself or you can ask the chairs or the secretary to do so. So there will be a written notice of this posted as well.
-There already has been a notice posted, so you can just refer to that.
+DE: I also want to note that these notes are not intended to contain personal information, and they’re available to be edited now or later in the Google Docs, so everyone in the committee has access to those. If you feel like a comment of yours has been inaccurately described or want to rephrase it to make it more clear, you’re really encouraged to do so. And further, any information deleted, you can do so yourself or you can ask the chairs or the secretary to do so. So there will be a written notice of this posted as well. There already has been a notice posted, so you can just refer to that.
 
 USA: Moving on, let us go through our housekeeping. So, okay, the approval of last meeting’s minute and adoption of the current agenda. Let’s spend a few seconds to see if anybody has any objections. Please speak up if you have any objections with the last meeting’s minutes, which should have been published, as well as the current agenda for this meeting.
 
@@ -96,15 +93,13 @@ USA: Thank you very much, and we appreciate it.
 
 SHN: Thank you.
 
-USA: All right. Since there is nothing else in the queue, I suppose we can move on to the next item,
-which is 262 status updates..
+USA: All right. Since there is nothing else in the queue, I suppose we can move on to the next item, which is 262 status updates..
 
 ## ECMA-262 Status Updates
 
 Presenter: Kevin Gibbons (KG)
 
-KG: Okay, this will be an extremely brief update. There were no editorial changes and no normative changes. We have the same list of upcoming and planned work. Also, the spec was cut last meeting.
-There will be a formal vote later and not as part of this presentation. That’s it. Thanks.
+KG: Okay, this will be an extremely brief update. There were no editorial changes and no normative changes. We have the same list of upcoming and planned work. Also, the spec was cut last meeting. There will be a formal vote later and not as part of this presentation. That’s it. Thanks.
 
 KG: We did do a bunch of small editorial tweaks. It’s not like we just stopped working for last two months. It’s just that not much was particularly worth calling to the attention of the delegates.
 
@@ -261,7 +256,8 @@ DE: If this makes sense, I will review it briefly, thanks. This is a good exampl
 CDA: There is also a +1 from JHD.
 
 USA: And that is it. So I think you have a lot of support. Would you like to conclude?
-MF : No I think that is all, thank you everyone.
+
+MF: No I think that is all, thank you everyone.
 
 USA: I guess we can spend a couple of minutes summarizing. How do we do this, and pull up the notes and do it collaboratively or?
 
@@ -289,8 +285,7 @@ Presenter: Micheal Ficarra (MF)
 
 MF: This is the entire text for the well-formed strings proposal. The proposal adds isWellFormed and toWellFormed. We did not iterate on this too much since this was uncontroversial through its whole life.
 
-MF: As far as implementation status we have two shipping, Safari and Chrome since March,
-Firefox has recently implemented this proposal, and we have polyfills in core-js and also these methods are polyfilled individually.
+MF: As far as implementation status we have two shipping, Safari and Chrome since March, Firefox has recently implemented this proposal, and we have polyfills in core-js and also these methods are polyfilled individually.
 
 MF: We have tests from JHD, he wrote tests a while back and they were merged a while back. And we have a PR for 262 that has been approved by the other editors. So in summary, we have I believe met all criteria for stage 4. And that is all for stage 4.
 
@@ -612,8 +607,7 @@ RBN: I have not had a chance to speak. And my point is a little bit broader than
 
 GB: To clarify, you say that is also for the static case and not just the dynamic case. How would the metaproperty solve the problems that static source imports solve which we have been describing for the the last few weeks?
 
-RBN: That was the question I had, so an import resolve call or even import source at the top level that isn’t a condition is still statically analyzable and still be a part of the module graph,
-does not depends on you actually saying that I will write a top level import declaration but a call – except for possibly an exception you would normally have purchased, if you don’t –
+RBN: That was the question I had, so an import resolve call or even import source at the top level that isn’t a condition is still statically analyzable and still be a part of the module graph, does not depends on you actually saying that I will write a top level import declaration but a call – except for possibly an exception you would normally have purchased, if you don’t –
 
 GB: The problem with dynamic code if you don’t know whether it will run or not, you cannot treat it as part of static build optimization. That is just parts of import system and we know that the top level execution of this module will require this JavaScript module source or web assembly module source to be in a compared form and furthermore not be evaluated, and from a security perspective that is a difficult property to import. Something similar to what you are describing is resource imports which we do describe in the same phase module where you can retain a handle on the resource through import system. And we did explore it just that primitive and we went through a period in our early decision exploration and if it is resource primitive was enough to capture all the requirements that we needed and what we determined if even with a resource primitive you still have the CSP problem because you don’t know how the resource will be used. And you have you still have some kind of static analyzability problem because now the resource is being used in dynamic code. So I think that direct relation between the module system which is how users interacts and how they gain access to resources and the usage of those resources, that is absolutely fundamental. And for modules in particular, that is how users get access to modules. So it is quite surprising to hear you say that you not how you get access to the module.
 

meetings/2023-05/may-17.md

@@ -90,8 +90,7 @@ RPR: Within the 60-day period, yes.
 
 ### Conclusion
 
-TC39 has approved ES2023 (ECMA-262 + ECMA-402) by acclamation.
-Subject to no objections being raised during the 60-day opt-out, this will be proposed to the Ecma GA for formal approval in June 2023.
+TC39 has approved ES2023 (ECMA-262 + ECMA-402) by acclamation. Subject to no objections being raised during the 60-day opt-out, this will be proposed to the Ecma GA for formal approval in June 2023.
 
 ## Intl.ZonedDateTimeFormat for Stage 1
 
@@ -249,7 +248,6 @@ CZW: So OpenTelemetry instruments user interaction, and we read APIs to create t
 CZW: And similarly, the resource timings has the similar problem. It cannot tell the initiated -- the -- cannot tell the initiator from the resource timing entries, and currently without resource timing initiator info, the telemetry just iterates the entry list to find the matching spans and associated that found entry with span to record the network event. And if the web platforms can attach in the chasing spans to the performance entries or if we cap just the async context, it will be very straightforward for OpenTelemetry to associate the network event with the fetch -- with the request expanse. Apart from the user monitoring, web platforms can also take advantage of the async context to propagate task attributions like execution priority or fetch priority or privacy protection meta data, et cetera. And that’s all of the -- of today’s use case recap. And next will be the normative changes we made in the past months. The first is that we are splitting the async context class the two class. One async snapshot and async local class. The normative change is still pending and being discussed in the PR number 55. The first async local class is the async context instance message renamed as asynclocal. And the asynclocal’s value is implicit through co-stacks like the previous async context instance. And the values are preserved across async boundaries. And notably, this change is still pending, and the name is still open to suggestions. Like, we have another suggestion as the I think variable.
 
 CZW: Next is the async snapshot. The previous AsyncContext.wrap becomes an AsyncSnapshot class. AsyncSnapshot captures the account state of the async context, and can be reviewed for multiple callbacks, so it can be made automatically to extend the async snapshot to be like the recurring and run the query in the async snapshot multiple times.
-Writer change*
 
 CZW: Also, there are suggestions to group the AsyncLocal and AsyncContext classes in a common namespace. There are precedents in the language. Like Temporal, and Intl. Of the 3 changes are still pending in the PR55. If there is any preference, comment in the PR so we can continue the change. And second normative change is constructor extensions. We add the AsyncLocal constructor can accept option and about option bag. There are two properties. The first is the name. It is mostly for debugging in Dev-tools. We can display the name. We can display the group of storage data mapping with AsyncLocal name and any can help for to distinguish each AsyncLocal instances with this descriptive name. And the second is default values. It is returned when there is no – when the get operation not enclosed in a AsyncLocal operate wrong code. So that, it can be convenient for setting debug cross-scheme for the AsyncLocal instances.
 
@@ -816,8 +814,8 @@ LCA: In the dynamic import form where you get returned the source directly. It
 
 JHD: I see.
 
-LCA: And then the other point about the dot in the static syntax, I don’t think we have any other syntax right now that has dots in it like this, where it’s like declaration that has dots in it.
-Maybe, but I don’t know. I don’t really like it. I prefer this.
+LCA: And then the other point about the dot in the static syntax, I don’t think we have any other syntax right now that has dots in it like this, where it’s like declaration that has dots in it. Maybe, but I don’t know. I don’t really like it. I prefer this.
+
 GB: Yeah. The dot would be a way around that ambiguity. But there’s no precedent for declarative dots in the language. That would be a new convention and again there’s like a – you don’t want to cause the confusion about what it’s doing.
 
 JHD: `import.source` for dynamic import doesn’t have precedent. I believe.
@@ -922,18 +920,15 @@ RPR: Michael?
 
 MM: Yeah. I had to jump in the queue. Mark thinks we agreed on – I don’t see we have come to that same conclusion. MM,, I don’t think it’s weird to ban binding named `from` in this position. We already ban let and some other conditionally like `yield` or something. Yeah. Yield. And a few other bindings from the declarations. I think it’s strictly a positive here
 
-MM: `let` and `yield` were listed as key words in strict mode starting in ES5. And I think they were already considered reserved before ES5.
-It’s only – they only come up as issue – well, let only comes up as an issue because it wasn’t reserved and not reserved in sloppy mode. And I don’t care about sloppy mode and I don’t think anybody should.
+MM: `let` and `yield` were listed as key words in strict mode starting in ES5. And I think they were already considered reserved before ES5. It’s only – they only come up as issue – well, let only comes up as an issue because it wasn’t reserved and not reserved in sloppy mode. And I don’t care about sloppy mode and I don’t think anybody should.
 
 MLS: This is the other Michael. I had problems with banning this here. It’s a possibility for developers . . . they will get a weird syntax error and not going to know why. They have to look it up. And they have to look it up in the spec. It just seems kind of weird.
 
 MF: MLS, which do you think is more common that will happen? That somebody accidentally uses from as a binding when they did not mean to or that someone wants to use from as a binding and gets told by the compiler that they can’t? I think that the accident case is going to be more common.
 
 MLS: Sure. I agree with that. But that’s – there’s still the other case where we don’t want – we are effectively disallowing a certain variable. And it’s – it’s not intuitive.
 
-GB: From what it’s worth, I don’t think there’s a complete form where from is misallocated. From a user perspective. It’s only if they repeat the key word from in the wrong position. Sorry, I guess I am trying to think of how someone would import the from binding by mistake or end up in a situation by mistake.
-For what it’s worth, you can already import from, from in the language.
-So I am not aware what the user concern here is.
+GB: From what it’s worth, I don’t think there’s a complete form where from is misallocated. From a user perspective. It’s only if they repeat the key word from in the wrong position. Sorry, I guess I am trying to think of how someone would import the from binding by mistake or end up in a situation by mistake. For what it’s worth, you can already import from, from in the language. So I am not aware what the user concern here is.
 
 WH: The concern is the third line on the slide. [titled “from” binding syntax error]