Need Review:
Needs implementation:
Needs minor change:
Keep an eye on…
Normative Spec Changes
Make super() throw after evaluating args
- Notes
- Proposal Link
- Summary: Inconsistency of behavior between evaluating arguments when calling new, as opposed to arguments called in the super constructor.
- Impact on SM: SM needs to change,
- Change:
- we currently throw BEFORE evaluating args on super, we will need to throw AFTER evaluating args on super.
- Bug
- Outcome: consensus reached for “stage 3”
Fix extending null
- Notes
- Proposal Link
- Summary: Make it possible to extend null using class syntax instead of setPrototypeOf. Currently a theoretical suggestion
- Impact on SM: Currently none.
- Outcome: Address the concern that the static semantics are being changed to runtime semantics such that SYG is satisfied, which will then trigger WH, BT, DE, and KM’s approval and thus consensus.
make async iterators next/return/throw not pass undefined when value is absent
- Notes
- Proposal Link
- Summary: The intention of this change is to make async iteration match sync iteration from the perspective of a userland iterator next method.
- Impact on SM: We would need to make async iteration and sync iteration output match
- Change:
- Sync output:
'args', []
- Async output:
'args', [undefined]
- bug – none yet
- Outcome: Waiting on tests for webcompat, if it’s compat I will implement it.
- Notes
- Proposal Link
- Summary: Only affect sloppy mode – We initially agreed on two scopes for param intialization. However the engines differ on their implementation
- *Impact on SM: We need to change.
- Change: See slide 4 vs slide 14 in the proposal link
- Outcome: Consensus reached to change this
TypedArray on prototypes web reality
- Notes
- Issue
- slides
- Summary: Proposed Change: Inside IntegerIndexed when the receiver is not the holder inside TypedArrays’ [[Set]], do an OrdinarySet.
- Impact on SM: We do not need to change, yet – if get is changed, we will need to change.
- Outcome: Consensus to change set but not get
make EnumerableOwnPropertyNames ordered
- Notes
- Proposal Link
- Summary: Removes a line of spec- “Removing this line has the effect of requiring those to be ordered the same way as Reflect.ownKeys, which is fully specified, rather than for-in, which is only partially specified”
- Impact on SM: None
- Outcome: Consensus reached
async-of grammar ambiguity
- Notes
- Proposal Link
- Summary: Exploring the general problem of what happens when we need more than a single token look ahead.
- Impact on SM: None - spec only change
- Outcome: We can solve this problem by disallowing for of loops that begin with async, but we need a solution for two-token lookahead in the future.
JSExplain demo
- Notes
- code
- Summary: Demo of a spec interpreter, as an educational tool.
- Impact on SM: None
- Outcome: None, but an interesting demo
- Notes
- Proposal Link
- Summary: We were under the impression that legacy regexp static fields were “for free”. Turns out they result in cache invalidation
- Impact on SM: None
- Outcome: Committee agrees with Shu’s analysis
Proposals Seeking Advancement to Stage 4
- Notes
- Proposal Link
- Slides
- Summary: Describing time in relative model is a common UX paradigm, this would make it a built in method.
- Impact on SM: Implemented, see Zibi for details
- Outcome: advance to stage 4
For-in order for stage 4
- Notes
- Proposal Link
- Slides
- Summary: ECMA-262 leaves the order of for (a in b) … almost totally unspecified, but real engines tend to be consistent in at least some cases. Over the years implementations have observed that anyone who wants to run code on the web needs to follow some constraints not captured by the spec.
- Impact on SM: No Change, only JSC is affected
- Outcome: Approved for Stage 4
Optional Chaining for Stage 4
- Notes
- Proposal Link
- Slides
- Summary: Introduce Optional chaining operator (?.)
- Impact on SM: No change
- Outcome: Approved for Stage 4
Nullish Coalescing for Stage 4
- Notes
- Proposal Link
- Slides
- Summary: introduce nullish coalescing operator (??)
- Impact on SM: No Change
- Outcome: No objections, advanced to stage 4
Proposals Seeking Advancement to Stage 3
Atomics.waitAsync for Stage 3
- Notes
- Proposal Link
- Slides
- Summary: Provide a new API, Atomics.waitAsync, that an agent can use to wait on a shared memory location (to later be awoken by some agent calling Atomics.notify on that location) without waiting synchronously (ie, without blocking). Notably this API is useful in agents whose [[CanBlock]] attribute is false, such as the main thread of a web browser document, but the API is not restricted to such agents.
- Impact on SM: Need to implement
- Outcome: Approved for Stage 3
Array.isTemplateObject update
- Notes
- Proposal Link
- Slides
- Summary: Provides a way for template tag functions to tell whether they were called with a template string bundle.
- Impact on SM: No Advancement, currently no change
- Outcome: None
Proposals Seeking Advancement to Stage 2
Dynamic Code Brand Checks for Stage 2
Dynamic Import Host Adjustment for Stage 2
- Notes
- Proposal Link
- Slides
- Summary: The dynamic import operator, import(…), loads code and initializes modules. Loading code from an untrustworthy source is an operation that cannot be undone.
This adjusts the host callout which enables dynamic loading. With it:
The host receives the original specifier (before it is stringified) so can use runtime type information to decide whether to allow code loading to proceed.
The host callout can control stringification and convey the result to FinishDynamicImport to avoid repeated stringification, and to integrate with default policies.
- Impact on SM: Need to review
- Outcome: Approved for Stage 2
Proposals Seeking Advancement to Stage 1
Array select/reject for Stage 1
- Notes
- Proposal Link
- Slides
- Summary: “filter” is confusing for people, add a new method such as “filterOut”
- Impact on SM: None for now
- Outcome: Stage 1 achieved.
Module attributes for Stage 1
- *Notes
- Proposal Link
- Slides
- Summary: The ES Module Attributes proposal is an investigation into providing inline syntax for module import statements to pass on more information alongside the module specifier, with an initial aim to support non-JS ESM module types.
- Impact on SM: None for now
- Outcome: Stage 1 achieved.
Operator Overloading for Stage 1
- Notes
- Proposal Link
- Slides
- Summary: Should JavaScript support operator overloading? It’s not clear one way or another whether operator overloading has enough benefit in terms of the complexity, in terms of language design, implementation work, and security surface. At the same time, there’s an argument that it’s better to provide general operator overloading than to overload operators for specific, additional, built-in constructs (and partly for this reason, Decimal was not added as part of ES6, although it might have been useful for JS developers).
- Impact on SM: None for now
- Outcome: Stage 1 Achieved
Just Updates
UUID Updates
- Notes
- Outcome: BCE will take this feedback. Will have a meeting with the W3C Web Crypto folks. Many people in the room thought randomness should come before randomUUID
Update on Function Implementation Hiding
- Notes
- Won’t touch name and length
Look into specifying differently for Waldemar/Allen
Look into more differentiated user story for library vs security case. If we see these are separable, then we should split the proposal into two addressing each of these use cases.
Look into readme improvements
go through issues and make sure all content is reflected on README
mention distinction between privileged/unprivileged code earlier in document
Possibly choose new directive names depending on discussion in GitHub issue
Standard Library Task Group for TC39
- Notes
- Summary: Standard Library Video call
- Outcome: It wasn’t rejected
Update on OOM Must Fail Fast
- Notes
- Summary: The ECMAScript specification nowhere mentions the possibility of running out of memory (OOM), and so cannot be correctly implemented on finite memory machines. Allocation in JavaScript is pervasive and implicit, implying that an OOM may happen anywhere in the execution of the program. If OOM threw a catchable error, computation within the agent would continue in an inconsistent state. Instead, we should immediately terminate the agent cluster, in order to abandon all unrepairable inconsistent state. Introduces concept of “nothrow”
Update on Promise Pipelining
- Notes
- Summary:This proposal adds eventual-send operations to JavaScript Promises, to express invocation of operations on potentially remote objects. We introduce the notion of a handled Promise, whose handler can provide alternate eventual-send behavior. These mechanisms, together with weak references, enable the creation of remote object communications systems, but without committing to any specific implementation. In particular, this proposal specifies a general mechanism for hooking in whatever host-provided remote communications facilities are at hand, without constraining the nature of those facilities.
Preserve Host Virtualizability for Stage 1