SpiderMonkey Small SpiderMonkey Logo
SpiderMonkey Large SpiderMonkey Logo piderMonkey

TC39 meeting, May 25-26 2021

•

Due to the recent changes on freenode, TC39 has moved to Matrix as its communication platform of choice. Read more here.

The TC39 meeting in May, one of the shorter two day meetings of the committee, primarily focused on more mature proposals, and no stage 1 proposals were introduced. Object.hasOwn moved forward quickly, reaching stage 3 at this meeting. In addition, Top-level await and RegExp Match Indices both moved to stage 4. Resizeable ArrayBuffers and Growable SharedArrayBuffers advanced to stage 3, and implementation will soon start in major browsers. This proposal introduces growable and shrinkable memory which will have implications for web developers as well as other specifications such as WebGPU and WebAssembly.

Realms, which is finally in a shape that browsers would be willing to implemented, was held back from stage 3 due to ergonomic concerns for certain use cases.

Keep an eye on…

  • Realms

Normative Spec Changes

None.

Proposals Seeking Advancement to Stage 4

RegExp Match Indices

  • Notes
  • Proposal
  • PR
  • Spec
  • Slides
  • Summary: RegExp Match indices allow retrieving the index of a given match. This is useful for applications such as text editors. You can now use it with the d flag, for example: /hello/d.
  • Impact on SM: Already Shipping,
  • Outcome: Advanced to stage 4.

Top Level Await

  • Notes
  • Proposal
  • PR
  • Slides
  • Summary: Top level await treats modules as large async functions and allows developers to use the await keyword at the top level of the module. This simplifies the modules which require immmediate async work.
  • Impact on SM: Already Shipping,
  • Outcome: Advanced to stage 4.

Proposals Seeking Advancement to Stage 3

Symbols as WeakMap Keys

  • Notes, More notes
  • Proposal
  • Slides
  • Summary: Symbols as Weakmap Keys proposal would allow users to use symbols in WeakMaps. This is currently forbidden, because certain symbols are never garbage collected and are similar to using a primitive value such as an integer in a Weakmap key. However, this only applies to things like registered symbols. The contention around this proposal is if the two types of symbols should be treated differently. This was not resolved in this meeting.
  • Impact on SM: Will need implementation
  • Outcome: Did not advance to stage 3.

ResizableArrayBuffer for Stage 3

  • Notes
  • Proposal Link
  • Slides
  • Summary: Introduces two new ArrayBuffers, one resizable, the other only growable (and shared).
  • Impact on SM: Will need implementation
  • Outcome: Advanced to stage 3.

Intl DisplayNames v2 for Stage 3

  • Notes
  • Proposal Link
  • Slides
  • Summary: Adds further coverage to the existing Intl.DisplayNames API. Was initially blocked from advancement while Issue #29 was sorted out.
  • Impact on SM: Will need implementation
  • Outcome: Advanced to stage 3.

Object.hasOwn for Stage 3

  • Notes
  • Proposal Link
  • Slides
  • Summary: Checking an object for a property at the moment, is rather unintuitive and error prone. This proposal introduces a more ergonoic wrapper around a common pattern involving Object.prototype.hasOwnProperty which allows the following: 
      let hasOwnProperty = Object.prototype.hasOwnProperty

  if (hasOwnProperty.call(object, "foo")) {
    console.log("has property foo")
  }

    to be written as:

      if (Object.hasOwn(object, "foo")) {
    console.log("has property foo")
  }
  • Impact on SM: Implemented
  • Outcome: Advanced to stage 3.

Realms for stage 3

  • Notes
  • Proposal Link
  • Slides
  • Summary: Realms exposes a new global without a document for use by JS programmers, think iframes without the document. This new proposal api is “isolated realms” which does not allow passing bare object specifiers between realms. This is an improvement from the browser architecture perspective, but it is less ergonomic. This issue was called out in the meeting, and the proposal did not advance as a result.
  • Impact on SM: No change
  • Outcome: Did not advance to stage 3.

Extend TimeZoneName Option Proposal for Stage 3

  • Notes
  • Proposal Link
  • Slides
  • Summary: Adds further options for the TimeZoneName option in Intl.DateTimeFormat, allowing for greater accuracy in representing different time zones.
  • Impact on SM: Implemented
  • Outcome: Advanced to stage 3.

Stage 3 Updates

Temporal update

  • Notes
  • Proposal Link
  • Slides
  • Summary: Introduces a new date/time library. If you would like to try it ahead of time, they have created a cookbook and polyfill for experimentation. During implementation in SpiderMonkey, a few issues were discovered in the spec. This update covers fixes to those issues.
  • Impact on SM: Implementation in Progress. Must not ship unflagged until IETF standardizes timezone/calendar string serialization formats

Proposals Seeking Advancement to Stage 2

Adopting Unicode behavior for set notation in regular expressions

  • Notes
  • Proposal Link
  • Slides
  • Summary: Add syntax & semantics for the following set operations: difference/subtraction (in A but not in B), intersection (in both A and B), nested character classes (needed to enable the above)
  • Impact on SM: Will need implementation.
  • Outcome: Advanced to stage 2.

Stage 2 Updates

Intl Enumeration API update

  • Notes
  • Proposal Link
  • Slides
  • Summary: Intl enumeration allows inspecting what is available on the Intl API. Initially, we had reservations that this could be used for fingerprinting. Mozilla did an analysis and no longer holds this concern. However, it is unclear if this api has usecases which warrant its inclusion in the language.
  • Impact on SM: Will Need implementation