TC39 meeting, July 20 - 23, 2020 | SpiderMonkey JavaScript/WebAssembly Engine

At this meeting a number of proposals moved from stage 3 (candidate proposal) to stage 4 (finished). WeakRefs was among the proposals to move to stage 4, introducing a capability to the web that was not present before. From an ergonomics point of view, logical assignment and Promise.any both advanced to stage 4. Two internationalization apis also advanced, DateTimeFormat and ListFormat. The only stage 2 proposal to move forward to stage 3 was an internationalization proposal, Intl.Segmenter. Adam Vandolder presented on the IteratorHelpers proposal, with the aim of moving it to stage 3 in September’s meeting.

As part of moving WeakRefs to stage 4, I presented a case for separating out the cleanupSome api, in order to gather more feedback before committing to a design. Shu-Yu Guo, from V8 also presented additional changes required for layering with HTML to the specification. As of this meeting, WeakRefs and FinalizationGroups are at stage 4, and we are waiting on the last pieces to fall into place in HTML.

Some progress was also made in ensuring that we write down our process and descision making constraints. I presented with Mark Miller a proposal for writing down language invariants. Some invariants are currently recorded, but not all of them. This results in some decisions requiring reconsideration. Finally, I presented a case for specifying our process more fully, namely to help clarify inconsistencies in advancing or not advancing a proposal. That discussion is currently ongoing.

As Always, here is a digest of the spec work to be done in the coming two months.

Normative Spec Changes

The following are small normative changes to the specification. These can have an impact on implementation.

Retroactive consensus on Unicode 13 property names and aliases

Notes
Proposal Link
- PR #1896
- PR #1939
Summary: Give consensus on the decision made in last meeting about writing non-normative text recording how Unicode 13 tables are updated.
Impact on SM: No change needed
Outcome: Consensus

Specify \8 and \9 in sloppy (non-template) strings

Notes
Proposal Link
Summary: \8 and \9 have divergent behavior in different browser. All engines agree that ‘\8’ and ‘\9’ are just ‘8’ and ‘9’ in sloppy mode, so specify that in B.1.2.
Impact on SM: No Change,
Outcome: Consensus

Adding Reflect[Symbol.toStringTag]

Notes
Proposal Link
Summary: Reflect is currently thee only builtin without Symbol.toStringTag. This adds that well known symbol to Reflect.
Impact on SM: Requires change to Reflect,
- Bug
Outcome: Consensus

Strictness check for object’s SetMutableBinding

Notes
Slides
Proposal Link
Summary: It is possible to have a Reference to a global variable or object-environment-record property which has been deleted. Normally, bare assignments to undeclared variables in strict mode cause ReferenceErrors. However, calling PutValue on a reference to a global variable which has been deleted since the reference was created does not throw a ReferenceError in strict mode. This circumvents a protection which strict mode is intended to provide.
Impact on SM: No change, we throw in this case,
Outcome: Consensus

Fix Function.toString for builtins

Notes
Proposal Link
Summary: Function.toString in chrome and V8 would include “get” as part of it’s toString print out, while Spidermonkey would not. According to the specification, “get” should be omitted. This PR updats it so that “get” should be included.
Impact on SM: Add “get”/”set” to our toString output for more informative output?,
- Bug
Outcome: Consensus

Host hooks for Job callbacks

Notes
Slides
Proposal Link
Summary: Introduces host hooks so that incumbent realms can be tracked (and enable the HTML side of the weakrefs proposal).
Impact on SM: No change in SpiderMonkey
Outcome: Consensus after side discussionn with Mark Miller and Bradley Farias.

Should eval?.() be direct eval?

Notes
Proposal Link
Summary: During the standardization of optional call, it was not noticed that this would cause eval?.() to be an indirect eval. This proposal changes that to being a direct eval instead.
Impact on SM: no change.
- Bug
Outcome: No consensus, leave as is. Was blocked on the basis that this would be a precident that would affect future proposals such as pipeline.

Forbid Numeric Separators in NonOctalDecimalIntegerLiteral fractional / exponent parts

Notes
Proposal Link
Summary: The proposed spec currently prohibits 09_1 but allows 09.1_1 and 09e1_1A. This behavior appears to be intentional, but is being raised again to see if we can have a better solution.
Impact on SM: No change in SpiderMonkey,
Outcome: Decision to not fix NonOctalDecimalIntegerLiteral, follow-up for a better solution to disallowing exponential parts - perhaps fractional parts as well - from NonOctals.

Proposals Seeking Advancement to Stage 4

The following are proposals seeking stage 4. At this point, most implementation work should be finished. All proposals seeking stage 4 in this round were accepted to stage 4.

Promise.any & AggregateError

Notes
Slides
Proposal Link
PR
Summary: Introduce Promise.any combinator, which will resolve if any promise in a list resolves.
Impact on SM: Implemented,
- Bug
Outcome: Consensus on stage 4

Intl.ListFormat

Notes
Slides
Proposal Link
Summary: The Intl.ListFormat object is a constructor for objects that enable language-sensitive list formatting.
Impact on SM: Implemented,
- Bug
Outcome: Consensus on stage 4

Intl.DateTimeFormat dateStyle/timeStyle

Notes
Slides
Proposal Link
Summary: This proposal adds two options to Intl.DateTimeFormat: dateStyle and timeStyle. These options give a compact way to request the appropriate, locale-specific way to ask for a date and time of given lengths.
Impact on SM: Implemented,
- Bug
Outcome: Consensus on stage 4

WeakRefs and FinalizationRegistry

Notes
Slides
Proposal Link
Summary: The WeakRef proposal encompasses two major new pieces of functionality:
- creating weak references to objects with the WeakRef class
- running user-defined finalizers after objects are garbage-collected, with the FinalizationRegistry class
Impact on SM: Implemented, except for incumbent realm tracking (HTML requirement),
- Bug
Outcome: Consensus on stage 4 without CleanupSome

Logical Assignment

Notes
Slides
Proposal Link
Summary: Introduce logical assignment operators ||=, &&=, and ??=.
Impact on SM: Implemented,
- Bug
Outcome: Consensus on stage 4

NumericLiteralSeparator

Notes
Slides
Proposal Link
Summary: Introduce separators to make large non-exponent numbers more readable, for example 12_345_567_890.
Impact on SM: Implemented,
- Bug
Outcome: Consensus on stage 4

Proposals Seeking Advancement to Stage 3

Proposals which are accepted to stage 3 will require implementer feedback. Of the proposals seeking stage 3, Intl.Segmenter was accepted, and the rest require further discussion.

Intl.Segmenter

Notes
Slides
Proposal Link
Summary: introduces locale specific sentence segmentation. For example, an English sentence is easy to segment at the character or world level. “Two chickens in a garden” can be split on any space. This doesn’t work for languages that do not use a space or similar as a word boundary. For example the same sentence in Japanese “にわにはにわにわとり” needs specific rules. “にわには” (in the garden), “にわ” (two) and “にわとり” (chicken) are the best word segementation points. Intl.Segmenter provides an API for this. Thank you to Makoto Kato for the clarification.
Impact on SM: To be implemented,
- Bug
Outcome: Consensus on stage 3.

Ergonomic Brand Checks

Notes
Proposal Link
Summary: Support proper ergonomic brand checks for classes. This proposal aims at improving the integrity of code and ensuring you can trust that an object is what an object says it is. This is a pretty specific detail to how JS works – typeof is unreliable because it can be spoofed. A proper brandcheck should not be spoofable. One example of a proper brand check is Array.is(), this utility allows any JS class to do this. The draw back? It is inconsistent with how the in keyword works. Previously in only worked with strings, and now it will work with private fields. There isn’t room here to describe it fully, but check out the proposal for more info.
Impact on SM: No consensus on stage 3, but we have an experimental impelementation ongoing,
- Bug
Outcome: No Consensus on stage 3. Concern raised by 360 regarding overloading the in operator, which at present only operates on strings on the left hand side.

Import Conditions

Notes
Slides
Proposal Link
Summary: Renames Module Attributes proposal. Introduce the ability to import file types other than JS, such as import x from "y" if {type: ...}. This would allow importing JSON and other file types.
Impact on SM: No impact until stage 3,
- Bug
Outcome: No Consensus on stage 3. Land patches for s/if/assert/ and permitting quotes around condition keys Split JSON modules into a separate Stage 2 proposal Land weakening of the host constraint, iterating on the wording in cooperation with SYG and BFS SYG, BFS, and WH to review before Stage 3 Proposal remains at Stage 2

Proposals Seeking Advancement to Stage 2

Proposals seeking stage two are to be accepted by the committee as “a problem that should be solved”, with the general approach suggested as being a potential solution.

.item() for Stage 2

Notes
Slides
Proposal Link
Summary: A TC39 proposal to add a .item() method to all the basic indexable classes (Array, String, TypedArray). It allows negative positioning like -1.
Impact on SM: No impact until stage 3.
- Bug
Outcome: Consensus on stage 2

Record and Tuple

Notes
Slides
Proposal Link
Summary: Records and tuples introduce immutable data collections of primitives to JS. There are some ambiguities to clarify around equality, namely positive and negative zero in js. How symbols should be treated was also discussed. Destructuring was discussed and omitted for the time being. The proposal will seek Stage 2 in July
Impact on SM: Experimental implementation ongoing.
- Bug
Outcome: Consensus on stage 2, concerns raised from implementers regardng implementability and possible solutions in Object.freeze and other proposals that have overlap with the immutability goal of Record and tuple.

JSON.parse source text access

Notes
Slides
Proposal Link
Summary: A proposal for extending JSON.parse behavior to grant reviver functions access to the input source text.
Impact on SM: No impact until stage 3
- Bug
Outcome: Consensus on stage 2 dependant on the 404 editor reviewing and working through the issues.

cleanupSome detached from the WeakRefs proposal and demoted to Stage 2

Notes
Slides
Proposal Link
Summary: CleanupSome is a method associated with WeakRefs and FinalizationGroups, which allows programmers to decide if they want to clean up the memory of some long running program that does not return to the event loop for a long time.
Impact on SM: No impact until stage 3
- Bug
Outcome: Consensus on demoting to stage 2.

Class static blocks for Stage 2

Notes
Slides
Proposal Link
Summary: Class static blocks provide a mechanism to perform additional static initialization during class definition evaluation.
Outcome: Added to agenda too late, No consensus on stage 2

Slice notation for Stage 2

Notes
Slides
Proposal Link
Summary: The slice notation provides an ergonomic alternative to the various slice methods present on Array.prototype, TypedArray.prototype, etc. For example: arr[1:3] to get element a, b, c, from arr = [a, b, c, d].
Impact on SM: No impact, blocked
Outcome: No consensus on stage 2. Mozilla raised concerns that this new syntax was not significantly better than the existing slice and could be hostile to learners. Google raised that the introduction of negative notation could cause issues, and it does indexing a different way from array syntax. Other concerns were raised that the syntax does not have enough of a benefit in order to be added.

Number.range for Stage 2

Notes
Slides
Proposal Link
Summary: Introduces a way to create an iterator for a range of a number type. For example Number.range(1,3) would give an iterator, yeilding one after the other of the elements[1, 2, 3].
Impact on SM: No impact, blocked
Outcome: No consensus on stage 2, ran out of time to discuss all issues.

Symbols as WeakMap keys for stage 2

Notes
Slides
Proposal Link
Summary: Allow Symbols to be used as WeakMap keys. This would provide an elegent solution to tracking objects (which can be garbage collected much like non-registered symbols) for Records and tuples.
Impact on SM: No impact until stage 3, temporarily blocked
Outcome: No consensus on stage 2. Blocked by Mozilla due to concerns of allowing permanent entries in a WeakMap/WeakSet. Need more time to consider arguments, and there was no time in this meeting to return to the topic.

Proposals Seeking Advancement to Stage 1

Proposals seeking stage 1 seek entry into the TC39 process. Minimal work required from implementations.

await operations

Notes
Slides
Proposal Link
Summary: Introduce await.all / await.race / await.allSettled / await.any to simplify the usage of Promises
Impact on SM: No change until stage 3.
Outcome: Consensus on stage 1

Array.prototype.unique()

Notes
Slides
Proposal Link
Summary: Introduce an array method that allows selecting only unique members in an array. Addresses the lacking property in Sets when working with objects.
Impact on SM: No change until stage 3.
Outcome: Consensus on stage 1

ResizableArrayBuffer and GrowableSharedArrayBuffer

Notes
Slides
Proposal Link
Summary: Introduces two new ArrayBuffers, one resizable, the other only growable (and shared) that would be implemented independantly of SharedArrayBuffer due to security concerns.
Impact on SM: No change until stage 3.
Outcome: Consensus on stage 1, needs discussion among implementers.

Async Context for Stage 1

Notes
Slides
Proposal Link
Summary: The goal of the proposal is to provide a mechanism to ergonomically track async contexts in JavaScript.
Impact on SM: None,
Outcome: No consensus on stage 1, the issue with dynamic scoping has still not been solved

Updates on Ongoing work

Decorators

Notes
Slides
Proposal Link
Summary: Introduces a set of builtin decorators. These builtin decorators can be composed to make custom ones. This proposal addresses concerns from implementers around the previous iteration of decorators.
Impact on SM: Will require review again,
- Bug
Outcome: The committee introduced contradictory requirements and these need to be relaxed.

Temporal

Notes
Slides
Proposal Link
Summary: Temporal introduces a better api for dealing with calendars and dates.
Impact on SM: Require major review,
- Bug
Outcome: Temporal will seek advancement to stage 3 in November. We should have done our review before thant point.

Upsert

Notes
Slides
Proposal Link
Summary: Add an api that ergonomically allows instantiating a missing element in a map, and updating it if necessary.
Impact on SM: No impact until stage 3,
- Bug
Outcome: After a lot of discussion with the champion, and presenting our (SpiderMonkey’s) issues with the proposal design and clarifying a few misunderstandings, we can to a different solution, which looks similar to getDefault.

IteratorHelpers

Notes
Slides
Proposal Link
Summary: Iterator helpers introduce array-like helper methods to iterator objects, such as map, filter, etc.
Impact on SM: Implemented, may require minor changes.
- Bug
Outcome: Two reviewers recruited for September review of spec.

Arbitrary Module Namespace Identifiers

Notes
Proposal Link
Summary: Allow the ability to create modules which integrate using non-IdentifierName bindings such as @foo
Impact on SM: No impact until stage 3,
Outcome: No substantial comments, can be a “needs consensus PR”.

Need Review:

Needs implementation:

Needs minor change:

Keep an eye on…