You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
@@ -209,7 +209,7 @@ DLM: Yeah, we support this normative change.
209
209
210
210
DE: In change sounds good to me. I think we should treat this similar to staged proposals in terms of merging it once we have multiple implementations and test. We could track PRs like this. Anyway, this seems like a very good change to me.
211
211
212
-
USA: Just FYI, we have tracking for everything, basically, sorry, for all normative PRs for ECMA 402, but noted. [https://github.com/tc39/ecma402/wiki/Proposal-and-PR-Progress-Tracking#ecma-402-prs](https://github.com/tc39/ecma402/wiki/Proposal-and-PR-Progress-Tracking#ecma-402-prs)
212
+
USA: Just FYI, we have tracking for everything, basically, sorry, for all normative PRs for ECMA 402, but noted. [tc39/ecma402/wiki/Proposal-and-PR-Progress-Tracking#ecma-402-prs](https://github.com/tc39/ecma402/wiki/Proposal-and-PR-Progress-Tracking#ecma-402-prs)
213
213
214
214
DE: Okay, great.
215
215
@@ -223,11 +223,11 @@ USA: And yeah, and with I guess a couple of supporting opinions, we achieved con
223
223
224
224
### Speaker's Summary of Key Points
225
225
226
-
Normative pull request [https://github.com/tc39/ecma402/pull/989](https://github.com/tc39/ecma402/pull/989) on ECMA 402 was presented to the committee for consensus and this PR added support for a notation option in the plural rules constructor for handling different non-standard notations.
226
+
Normative pull request [tc39/ecma402#989](https://github.com/tc39/ecma402/pull/989) on ECMA 402 was presented to the committee for consensus and this PR added support for a notation option in the plural rules constructor for handling different non-standard notations.
227
227
228
228
### Conclusion
229
229
230
-
The committee reached consensus on [the pull request]([https://github.com/tc39/ecma402/pull/989](https://github.com/tc39/ecma402/pull/989)), with explicit support from DE and DLM.
230
+
The committee reached consensus on [the pull request](https://github.com/tc39/ecma402/pull/989), with explicit support from DE and DLM.
231
231
232
232
## Normative: Mark sync module evaluation promise as handled
233
233
@@ -252,7 +252,7 @@ NRO: And then later when you actually handle the promise, so when you call .then
252
252
253
253
NRO: So that was Promises, and how does this interact with modules?
There are multiple types of modules in this spec, or well Module Records, which represent modules. There are a Module Record base class and two main types of actual Module Records. There are Cyclic Module Records andSynthetic Module Records. Cyclic records are modules that support dependencies. And this is some sort of abstract extract base class and our spec provides Source Text Module Records that are variant for JavaScript. For example, the web assembly imports proposals in the WebAssembly is proposing a new type of cyclic on the record, and for synthetic module records, and it’s just modules where you already know the exports and you have to wrap them with some sort of module to make them importable. The way module evolution works changed over the years. Like, originally there was this Evaluate method that would—it was on all module records, and it would trigger evaluation, and if there was an error returned a throw completion, otherwise a normal completion. But then when we introduced the top-level await, we changed the method to return the promise with the detail that only cyclic module records can actually await. If there’s any other type of the module records, like any type of custom host module, there’s a promise in there, returned by the Evaluate method, and this promise must already be settled. So the promise there is just to have a consistent API signature, and not actually used as a promise.
258
258
@@ -264,7 +264,7 @@ NRO: Then during the evaluation of `a.js`, we perform the steps from the slide b
264
264
265
265
NRO: So the fix here is to just change these InnerModuleEvaluation abstract evaluation to explicitly call the host hook that marks the promise as handled when we extract the rejection from the promise. And, well, editorially, I’m doing this as a new AO because it's used by the import defer proposal, and we’re going to have it inline in the Module evaluation algorithm.
266
266
267
-
NRO: Are there observable consequences to this? Yes and no. Technically this is a normative change, as example before, this is observable because it changes the way host hooks are called, and usually they affects how some events are fired. However, on the web, the only non-cyclic module records we have are syntactic model records and we already have the values, we already—we’re just packaging them in a module after creating them, so that promise is never rejected, and this is not observable. Outside of the web, we have commonJS, and when you import from a .cjs file, it would be wrapped in its own Module Record and we evaluate the particular CJS module in the `.Evaluate()` methodevaluation of the module record. However, NodeJS does not expose as rejected through their rejection event the promise for that internal module, because maybe they don’t actually create the promise, and don’t know how it’s implemented. So Node.js already implements the behavior that would be—that we will get by fixing this. Node does not implement the bug. So, yeah, to conclude, is there consensus on fixing this? There’s the pull request ([3535](https://github.com/tc39/ecma262/pull/3535)) already reviewed in the 262 repository.
267
+
NRO: Are there observable consequences to this? Yes and no. Technically this is a normative change, as example before, this is observable because it changes the way host hooks are called, and usually they affects how some events are fired. However, on the web, the only non-cyclic module records we have are syntactic model records and we already have the values, we already—we’re just packaging them in a module after creating them, so that promise is never rejected, and this is not observable. Outside of the web, we have commonJS, and when you import from a .cjs file, it would be wrapped in its own Module Record and we evaluate the particular CJS module in the `.Evaluate()` methodevaluation of the module record. However, NodeJS does not expose as rejected through their rejection event the promise for that internal module, because maybe they don’t actually create the promise, and don’t know how it’s implemented. So Node.js already implements the behavior that would be—that we will get by fixing this. Node does not implement the bug. So, yeah, to conclude, is there consensus on fixing this? There’s the pull request ([#3535](https://github.com/tc39/ecma262/pull/3535)) already reviewed in the 262 repository.
268
268
269
269
MM: Great. So I’ll start with the easy question. The—you mentioned the situation where the promise—there exists a promise that when born is already settled, and I understand why, and it all makes sense, I just want to verify that it does not violate the constraint, the invariant that user code cannot tell synchronously whether a promise is settled or not. That the only way—the only anything that user code can sense is asynchronously. It finds out that a promise is settled. Is that correct?
MM: So last time we brought this to the committee, it was called must fail fast, and it got stage 1, and then it got blocked from advancing from there for reasons I will explain. And this is a Stage 1 update. Since then, the proposal—we renamed the proposal “Don’t Remember Panicking.” So I’m going to linger on this slide for a little bit because this is the code example I’m going to use throughout the entire talk, so it’s worth all of us getting oriented in this code example. This is a simple money system. Don’t worry if you stop bugs, it’s purposefully a little bit buggy, which is—in order to illustrate some of the points.
@@ -207,7 +207,7 @@ No conclusion; we’ll discuss further in a continuation topic, including a temp
RBN: Today I want to discuss enum declarations. I am Ron Buckton, I work on the TypeScript team. Enum declarations are essentially enumerated types. Provide a finite domain of constant values that are obvious to indicate choices, discriminants and bitwise flags. And a staple from C-style languages, VB .NET. C#, Java, PHP, Rust, Python, the list goes on and on. The reasons we are discussing this are several. One, the ecosystem is rife with enumerated values. ECMAScript is `typeof`--String based. The DOM has `Node.type`, which has its enumerated values on the Node constructor, this is the same. Buffer encodings are string based, or a string based enumerated type essentially. And Node.js has constants that are enumerated type or value-like functionality. But there’s no grouping. For users there is really no standardized mechanism to define enumerated type, ones that can be used reliably by static type. We talked about ObjectLiterals. But there’s a reason why that’s not really the best choice for this. I will go into that in a moment.
JHD: Hi, everyone. RBR just became an Invited Expert. He and I are co-championing this proposal. `Object.propertyCount` is solving this problem that RBR is going to talk about is something I run into frequently, and so I was very excited to walk-through this when he approached me with the idea. RBR is a [Node TSC [Technical Steering Committee]]([https://github.com/nodejs/TSC](https://github.com/nodejs/TSC)) and core collaborator. And I will hand it over to him to present better than I would have been able to do. Go for it.
394
+
JHD: Hi, everyone. RBR just became an Invited Expert. He and I are co-championing this proposal. `Object.propertyCount` is solving this problem that RBR is going to talk about is something I run into frequently, and so I was very excited to walk-through this when he approached me with the idea. RBR is a [Node TSC Technical Steering Committee](https://github.com/nodejs/TSC) and core collaborator. And I will hand it over to him to present better than I would have been able to do. Go for it.
395
395
396
396
RBR: Thank you very much also for having me here. It’s the first time for me to be on the call. So very nice to—I am able to present. So like JavaScript I am pretty certain, every one of you has multiple times heard that JavaScript is a slow language. And thanks to JITs this is mostly no longer true, in most situations, and one thing is, however, that has bothered me, and because the language doesn’t provide any way to implement a lot of algorithms in a very performant way. And one is relating to counting the properties of an object in different ways. So it’s a very common JavaScript performance bottleneck I have run into.
397
397
@@ -576,7 +576,7 @@ Not everyone in committee was convinced of some of the aspect of the broader sco
DLM: Sure. Tough. I would like to present some feedback about the explicit resource management proposal. Quick reminder about what a specific resource management is. Basic idea the idea is to add a `using` keyword, along with a `Symbol.dispose` and the concept of `DisposableStack`. And generally the idea allows for automatic disposal of resources when the use—when using variable leaves scope. For example this simple little thing here. Where are we in SpiderMonkey. It’s fully implemented. It’s currently shipped in Nightly, but disabled behind a prop and the current implementation follows the spec. In particular, it’s currently maintaining an explicit list of resources to dispose at runtime.
582
582
@@ -606,11 +606,11 @@ DLM: Okay. Great! Thank you very much.
606
606
607
607
### Summary
608
608
609
-
Allowing the `using` statement in a switch statement with fallthrough complicates implementations. If we disallow this use case, implementations can desugar to try/finally blocks which is simpler and more efficient. The proposal champion put together a pull request for this change: [https://github.com/rbuckton/ecma262/pull/14](https://github.com/rbuckton/ecma262/pull/14).
609
+
Allowing the `using` statement in a switch statement with fallthrough complicates implementations. If we disallow this use case, implementations can desugar to try/finally blocks which is simpler and more efficient. The proposal champion put together a pull request for this change: [rbuckton/ecma262#4](https://github.com/rbuckton/ecma262/pull/14).
610
610
611
611
### Conclusion
612
612
613
-
Consensus to merge [https://github.com/rbuckton/ecma262/pull/14](https://github.com/rbuckton/ecma262/pull/14).
613
+
Consensus to merge [rbuckton/ecma262#14](https://github.com/rbuckton/ecma262/pull/14).
614
614
615
615
## Non-extensible applies to Private for stage 1, 2, 2.7
616
616
@@ -766,7 +766,7 @@ MM: Okay. Great.
766
766
767
767
### Speaker’s Summary
768
768
769
-
* MM presented a new proposal, broken off from [proposal-stabilize]([https://github.com/syg/proposal-nonextensible-applies-to-private](https://github.com/syg/proposal-nonextensible-applies-to-private)), co-championed by SYG and others. It proposes to make private fields respect `Object.preventExtensions` .
769
+
* MM presented a new proposal, broken off from [proposal-stabilize](https://github.com/syg/proposal-nonextensible-applies-to-private), co-championed by SYG and others. It proposes to make private fields respect `Object.preventExtensions` .
770
770
* This proposal would patch up the current counterintuitive behavior of private fields not obeying non-extensibility, prevent hidden state creation via private fields, and improve performance so that nonextensible objects can have fixed memory layouts.
771
771
* The proposal is not backwards compatible and might rarely break existing correct code.
772
772
* Google has deployed usage counters and found minimal impact, but some websites in Germany (some which use a German GIS framework called Cadenza) might be affected. One website has minimal likely impact; it is for a temporary music festival. Google is trying to reach out to the affected German websites and Cadenza, but further help with outreach was requested by SYG.
MLS: This is a continuation from our conversation that we had in Seattle. And I asked for an hour, I don’t think this is going to take an hour. But we will see. This is caused conversation in the past. I think from Seattle there’s general agreement there is a problem we need to deal with single dissenters. It’s rare, but there’s been some issues in the past. There’s also, I took away from Seattle, there’s no desire for like a major process change. That we—our social norms seem to be enough to guide us for 9X% where X is a pretty big number. 98%. And it also, I took at here’s no need to have two objectors. I originally proposed 5% at Seattle and people thought that was too onerous and have to figure out what is 5% so on and so forth.
0 commit comments