Stage 4, ready to ship: Promise.allSettled bug Two syntax changes have moved to stage 3, nullish coalescence and optional chaining A lot of discussion around built in modules. No forward movement. Issues with Weakref – it cannot be tested in the current test262 setup. Discussion around how to address this.
Test 262 report
Test262 is having problems with weak refs. It is difficult to detect problems because all of the browsers have different garbage collectors. We discussed the possibility of adding a GC hook for the tests, but it was discarded. There are also security implications. There was no clear resolution here, but it highlights an issue.
TC53 Liaison Report
The liaison reported a change to the name TC53: EcmaScript Modules for Embedded Systems
This highlights their support for builtin modules. They explicitly voiced their support for split namespaces, which Mozilla opposes.
Accepted normative changes
Disallow internal methods returning
- Assists formalisation and implementors
- Disallow BigInt literals for Annex-B non-octal digits
- Annex B was causing issues with the spec. It was not resolvable so we disable non-octal digits
Loosening idempotency requirements for HostImportModuleDynamically to enable retrying failed fetches
- Approved to merge the change
- issue with built in modules name spacing
Proposals Advanced Stage 4
Proposals Advanced Stage 3
- Moved forward to stage 3
Uses parens to address issue with conflicts between and ?? — grammar needs to be rewritten
Proposals Advanced Stage 2 or Stage 1
- Set of iterator methods to make it easier to work with iterators. Rather than using array.from, these methods are lazy. Example,
- advanced to stage 2
Explicit Resource Management
- sample code
- Moved forward to stage 1
- Allows creating a reversed iterator, a bit incomplete in its formulation
Proposals with blocked advancement
- introduces a standard library
- two points of contention:
- having a unified namespace, or a split one
- loading from scripts, synchronously
- issue two was shown to be out of order
- blocked from advancement to stage 2 on issue 1
- blocks work on temporal and other standard library work
- specifies behavior more fully based on the V8 implementation
- has consistent behavior with spidermonkey (requires no change)
- test cases are not substantial enough
- no advancement
- investigate web compatibility for matchAll behavior, if we can make both global by default
- go with option 2 now, advancement blocked.
- no advancement, and potentially indefinite blocker
- potentially withdrawn
- mask toString to hide function implementation
- further investigation needed. Seeking stage 3 at next presentation
Proposals with unclear resolution
- no resolution
- sample code
- unclear resolution
- kebab case or camel case?
- Recommendation is not made on Option 3 (camelCase).
- Discussion will be taken offline.