diff --git a/meetings/2023-05/may-15.md b/meetings/2023-05/may-15.md index b48e008b..27b70340 100644 --- a/meetings/2023-05/may-15.md +++ b/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. diff --git a/meetings/2023-05/may-17.md b/meetings/2023-05/may-17.md index d2e81b3e..72b56069 100644 --- a/meetings/2023-05/may-17.md +++ b/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,8 +920,7 @@ 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. @@ -931,9 +928,7 @@ MF: MLS, which do you think is more common that will happen? That somebody accid 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] diff --git a/meetings/2023-05/may-18.md b/meetings/2023-05/may-18.md index 85ca0137..f22ddb54 100644 --- a/meetings/2023-05/may-18.md +++ b/meetings/2023-05/may-18.md @@ -150,8 +150,7 @@ KG: So I think if you don’t use the helper and you don’t like manually call SYG: Sorry. I retract my original suggestion. I don’t think it’s important that the buffer ahead itself, that that particular method call is the thing that opts you into out of order. But the out-of-order opt-in makes sense as a buffering call. Like buffer ahead, you have `bufferAhead` as in order, but have `ooBufferAhead` or something. The unit – yeah. -KG: That makes sense. Unfortunately, you can’t split them up. Whether things settle out of order has to be a property of the mapper. Not of the consumer of the mapper. If `.map` is constrained to give you things in order, or `.filter` is a better example, then you can add a buffering helper and the buffering helper like, can’t do anything about the fact that the things that its buffering settle in order. -It could, you know, vend them in a different order if it really wanted to. But if the underlying thing is settling things in order, preserving sequence order, then they are going to be in the buffer in order and you can’t start going out of order in a useful way, inside of the buffer. +KG: That makes sense. Unfortunately, you can’t split them up. Whether things settle out of order has to be a property of the mapper. Not of the consumer of the mapper. If `.map` is constrained to give you things in order, or `.filter` is a better example, then you can add a buffering helper and the buffering helper like, can’t do anything about the fact that the things that its buffering settle in order. It could, you know, vend them in a different order if it really wanted to. But if the underlying thing is settling things in order, preserving sequence order, then they are going to be in the buffer in order and you can’t start going out of order in a useful way, inside of the buffer. SYG: I think I see. Okay. That’s unfortunate. @@ -211,8 +210,7 @@ SYG: My understanding is that this enables some parallelism: if you get a host-v KG: Yeah. I am not imagining that engines would implement any parallelism. Like, CPU-level parallelism. Only network etc. -KG: Okay. So we are past time. Thank you for the discussion. I think the order one definitely we are going to need to talk about prior to everything else . . . that discussion will have to happen first. -I did want to check; it sounded like no one voiced objections where values get lost. MF didn’t like that we have this ordering constraint. But I am going to assume that no one thinks this problem of values disappearing into the void in the case of exceptions is a big deal. And assuming we do ultimately settle on this order preserving property, that we will probably keep this consistency property in the face of values getting lost. And we haven’t talked about flatMap, but I wanted to raise it and depending on how the discussion of ordering goes, we can – if people have thought about how to address these please open an issue or ping me. +KG: Okay. So we are past time. Thank you for the discussion. I think the order one definitely we are going to need to talk about prior to everything else . . . that discussion will have to happen first. I did want to check; it sounded like no one voiced objections where values get lost. MF didn’t like that we have this ordering constraint. But I am going to assume that no one thinks this problem of values disappearing into the void in the case of exceptions is a big deal. And assuming we do ultimately settle on this order preserving property, that we will probably keep this consistency property in the face of values getting lost. And we haven’t talked about flatMap, but I wanted to raise it and depending on how the discussion of ordering goes, we can – if people have thought about how to address these please open an issue or ping me. ### Speaker's Summary of Key Points @@ -464,6 +462,7 @@ MLS: That’s doable. The other thing is that, since you’re making this on Obj JHD: That’s how it’s specified in this request. That’s a change. These currently take any arbitrary iterable. JRL: JHD, can you show the groupBy abstract operation? There’s going to be calls to GetIterator and we are doing iterator to close, IteratorNext. All of regular iterator stuff this. Was done to match `Array.from`, I believe. + JHD: The only part that wouldn’t match `Array.from` is the arraylike fall back that `Array.from` has. KG: It also matches `Object.fromEntries` et cetera. We generally consume iterables, everywhere except in `Array.prototype` methods. @@ -529,9 +528,7 @@ Presenter: Kevin Gibbons (KG) - [proposal](https://github.com/tc39/proposal-decorator-metadata) - [spec](https://github.com/pzuraq/ecma262/pull/10) -KG: There were a couple of changes proposed during the presentation. And so there hadn’t been time for spec text to be written and reviewed. And the spec text has now been written and reviewed. And it implements the thing that we discussed during the meeting. I can pull it up on screen, if you would like. -I guess I will do that either way. I have had the chance to review it and it looks good to me. -So formally asking for Stage 3 for decorator metadata with the semantics discussed earlier at the meeting. And in particular, the relevant thing is that the decision about whether to set the metadata at all on the class depends on whether there are any decorators, the decision about whether to look up the decorator from the parent depends on whether there is a syntactic parent, and finally, there is a non-configurable and non-writable null, `Symbol.decorator` property on Function.prototype. +KG: There were a couple of changes proposed during the presentation. And so there hadn’t been time for spec text to be written and reviewed. And the spec text has now been written and reviewed. And it implements the thing that we discussed during the meeting. I can pull it up on screen, if you would like. I guess I will do that either way. I have had the chance to review it and it looks good to me. So formally asking for Stage 3 for decorator metadata with the semantics discussed earlier at the meeting. And in particular, the relevant thing is that the decision about whether to set the metadata at all on the class depends on whether there are any decorators, the decision about whether to look up the decorator from the parent depends on whether there is a syntactic parent, and finally, there is a non-configurable and non-writable null, `Symbol.decorator` property on Function.prototype. [on the queue] Support from DE, RBN, SYG diff --git a/meetings/2023-07/july-11.md b/meetings/2023-07/july-11.md index 534ed5a6..1d284850 100644 --- a/meetings/2023-07/july-11.md +++ b/meetings/2023-07/july-11.md @@ -151,8 +151,7 @@ USA: All right. Thank you to our secretaries. That’s all for this item. ### Summary -The slides were reviewed, and suggested to read the documents of interest as noted in the Annex. -Congratulations: Standards approved by GA 27 June and posted on website: +The slides were reviewed, and suggested to read the documents of interest as noted in the Annex. Congratulations: Standards approved by GA 27 June and posted on website: - ECMA-262 14th edition – ECMAScript® 2023 Language Specification - ECMA-402 10th edition – ECMAScript® 2023 Internationalization API specification @@ -311,8 +310,7 @@ Four PRs needing consensus were presented based on TG2 work and findings. Consensus on #709, #768, #786 and intl-numberformat-v3#130. -TC39 Plenary decided the following: -Consensus on #709, #768, #786 and intl-numberformat-v3#130. +TC39 Plenary decided the following: Consensus on #709, #768, #786 and intl-numberformat-v3#130. '#709': when we pass an options object to the DateTimeFormat constructor, the property reads are user-visible yet irregular. This PR makes it so every property is read only once. diff --git a/meetings/2023-07/july-12.md b/meetings/2023-07/july-12.md index 24f54013..0c1a71d0 100644 --- a/meetings/2023-07/july-12.md +++ b/meetings/2023-07/july-12.md @@ -119,9 +119,7 @@ RPR: And it sounds like SHN is doing the detail of each point. That would be som ### Summary and conclusion -The discussion summary and conclusions needs to include the salient points, agreements reached and next steps. -The summary should not be as short as: “this was discussed, we agree to go to Stage 3.” It should highlight the most essential items so not to lose track of what is ongoing. -The summary should indicate the issues discussed and important points and provide clear indication of what to consider when anyone reviews the summary in future. +The discussion summary and conclusions needs to include the salient points, agreements reached and next steps. The summary should not be as short as: “this was discussed, we agree to go to Stage 3.” It should highlight the most essential items so not to lose track of what is ongoing. The summary should indicate the issues discussed and important points and provide clear indication of what to consider when anyone reviews the summary in future. ## Stage 3 update of Intl Locale Info API @@ -258,9 +256,7 @@ FYT: I don’t know how to do that. Let me see Consensus was not reached for the proposal Intl Locale Info API, [PR#70](https://github.com/tc39/proposal-intl-locale-info/pull/70). This item needs to be addressed TG2 for discussion, if taking/using the number 1 to 7 as the input, the option bag, and also as a return value for the first day of week. -Summary: -The key arguments is that: -Temporal already have defined 1 to 7, away from the dates, so we should not have a third way to do the weekday representation. +Summary: The key arguments is that: Temporal already have defined 1 to 7, away from the dates, so we should not have a third way to do the weekday representation. Currently in Stage 3, already for a while, including the current issue there are three more issues and will be discussed, Issue 30, issue 71. Issue 73, in the coming TG2 and hopefully reach Stage 4 by November. Noting both Chrome and Safari have shipped this version, but not Mozilla. @@ -494,18 +490,13 @@ KG: Okay. Thanks. I will do that. ### Summary -A method for writing to an existing buffer as part of the streaming API, was presented, which had a couple of open questions including whether to have offset parameters. The committee was split on having offset parameters, but expressed no disagreement with my positions on the other open questions namely: -the decision to have separate methods for writing to an existing buffer the naming question, proposal to use `toChunked`. -Committee is not universally convinced to do streaming as part of this proposal. -There is no agreement on the use of the offset parameters. +A method for writing to an existing buffer as part of the streaming API, was presented, which had a couple of open questions including whether to have offset parameters. The committee was split on having offset parameters, but expressed no disagreement with my positions on the other open questions namely: the decision to have separate methods for writing to an existing buffer the naming question, proposal to use `toChunked`. Committee is not universally convinced to do streaming as part of this proposal. There is no agreement on the use of the offset parameters. ### Conclusions No universal agreement, whether the streaming API should be part of the proposal -Have more discussions and then present a proposal with spec text for both the streaming and one-shot versions, so the committee can make a decision on the streaming versions. -Anticipate Stage 3 for one-shot or streaming version. -Await implementation feedback on if the offset parameters are necessary for performance +Have more discussions and then present a proposal with spec text for both the streaming and one-shot versions, so the committee can make a decision on the streaming versions. Anticipate Stage 3 for one-shot or streaming version. Await implementation feedback on if the offset parameters are necessary for performance ## Explicit Resource Management (continuation) diff --git a/meetings/2023-07/july-13.md b/meetings/2023-07/july-13.md index e16128f2..faa43b4b 100644 --- a/meetings/2023-07/july-13.md +++ b/meetings/2023-07/july-13.md @@ -167,9 +167,7 @@ USA: Thank you, Shane. ### Summary and conclusion -The purpose of this presentation is to layout a user building of Wasm library, and highlight the challenges and road blocks encountered. Various, five to seven, proposals are noted in the slide deck. -One of the purpose is to draw a big picture for how these tie together to solve a real use case. We talked about all in isolation. It is good to see how they tie together to solve a real problem that has big implications of deploy libraries written in any language to the web platform. -A detailed discussion was had by everyone. +The purpose of this presentation is to layout a user building of Wasm library, and highlight the challenges and road blocks encountered. Various, five to seven, proposals are noted in the slide deck. One of the purpose is to draw a big picture for how these tie together to solve a real use case. We talked about all in isolation. It is good to see how they tie together to solve a real problem that has big implications of deploy libraries written in any language to the web platform. A detailed discussion was had by everyone. ## Optional chaining in assignment LHS for stage 1 or 2