TC39 meeting, April 19-21 2021

In this TC39 meeting, the updates to JavaScript Classes around private state have moved to stage 4. Other proposals of note this meeting were proposals related to ArrayBuffers, notably resizable ArrayBuffers and a new proposal, introducing read-only ArrayBuffers and fixed views into ArrayBuffers. Read-only ArrayBuffers are not a new ArrayBuffer, but rather a way to freeze existing ArrayBuffers so that they are not modified accidentally. Fixed views into ArrayBuffers would have the goal of not exposing more than the intended view of an ArrayBuffer to a third party.

One of the interesting new proposals is Object.has or Object.hasOwn. This would supply developers with a convenient shorthand. The following:

let hasOwn = (obj, prop) => Object.prototype.hasOwnProperty.call(obj, prop);

if (hasOwn(object, "foo")) {
  console.log("has property foo");
}

could instead be written as:

if (Object.hasOwn(object, "foo")) {
  console.log("has property foo")
}

This is a tricky corner case, and this would simplify things.

Pattern matching was brought back with an update. The proposal has a number of champions now, and a new effort to cleanly define the syntax. The record/tuple champions brought a new proposal that would help align how mutable and immutable structures have symmetry in their methods.

Needs minor change:

None.

Keep an eye on…

• Pattern Matching
• Read-only ArrayBuffers and Fixed views
• Change array by copy

Normative Spec Changes

None.

Proposals Seeking Advancement to Stage 4

Class fields, private methods, and static class features

• Notes
• Proposal Link Class Fields
• Proposal Link Private Methods
• Proposal Link Static Class Features
• PR
• Slides
• Summary: Class fields, private methods, and static class features are three proposals that make up a revision of classes in JavaScript. The proposals, due to their complexity, waited until all three major browsers had completed their implementations before seeking stage 4.
• Impact on SM: Already Shipping,
  • Bug
• Outcome: Advanced to stage 4.

Proposals Seeking Advancement to Stage 3

Intl Locale Info for Stage 3

• Notes
• Proposal Link
• Slides
• Summary: An API to expose information of locale, such as week data (first day of a week, weekend start, weekend end), hour cycle, measurement system, commonly used calendar, etc.
• Impact on SM: Needs implementation
  • Bug
• Outcome: Advanced to Stage 3.

ResizableArrayBuffer for Stage 3

• Notes
• Proposal Link
• Slides
• Summary: Introduces two new ArrayBuffers, one resizable, the other only growable (and shared). The update to resizable ArrayBuffers introduces implementation defined rounding.
• Impact on SM:
  • Bug
• Outcome: Did not achieve consensus. Moddable requested more time to investigate the cost of having two new globals on their engine. The current outcome is that instead of introducing these new globals, we will instead overload the name, with a parameter (name to be determined) that will allow for the creation of a resizable/growable arraybuffer/sharedarraybuffer.

Intl DisplayNames v2 for Stage 3

• Notes
• Proposal Link
• Slides
• Summary: Adds further coverage to the existing Intl.DisplayNames API.
• Impact on SM: Will Need implementation
  • Bug
• Outcome: Did not achieve Consensus. There were a few requests for more investigation and time to resolve issues. Specifically, around CLDR and its defined language display names and whether they should all be supported in #29.

Stage 3 Updates

Import Assertions update

• Notes
• Proposal Link
• Slides
• Summary: The Import Assertions proposal adds an inline syntax for module import statements to pass on more information alongside the module specifier. The initial application for such assertions will be to support additional types of modules in a common way across JavaScript environments, starting with JSON modules. The syntax allows for the following.

    import json from "./foo.json" assert { type: "json" };
  

  The update focused on the question of “what do we do when we have an assertion that isn’t recognized?”. Currently if a host sees a module type assertion that they don’t recognize they can choose what to do. There wasn’t a resolution here so far.

• Impact on SM: Implementation in Progress
  • Bug

Proposals Seeking Advancement to Stage 2

Extend TimeZoneName Option Proposal for Stage 2

• 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: Will Need implementation
  • Bug
• Outcome: Advanced to stage 2.

Symbols as WeakMap keys for Stage 2

• Notes
• Proposal Link
• Slides
• Summary: Allows symbols in WeakMap Keys. The discussion focused on the potential issue of using globally shared symbols in a weakmap, as these would effectively be strongly held. As this is already possible in JavaScript (globals can be keys in a weakmap and are also never garbage collected), it was determined that this was not a significant risk.
• Impact on SM: Will Need implementation
  • Bug
• Outcome: Advanced to stage 2.

Stage 2 Updates

Intl.NumberFormat V3 Stage 2 Update

• Notes
• Proposal Link
• Slides
• Summary: A batch of internationalization features for number formatting. This update focused on changes to grouping enums, rounding and precision options, and sign display negative.
• Impact on SM: Will Need implementation
  • Bug

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
  • Bug

Proposals Seeking Advancement to Stage 1

Read-only ArrayBuffer and Fixed view of ArrayBuffer for Stage 1

• Notes
• Proposal Link for Read-Only ArrayBuffer
• Proposal Link for Fixed view
• Slides
• Summary: These two proposals introduce ways to constrain ArrayBuffers. The first, read-only ArrayBuffers, would allow you to freeze arraybuffers much the way that you can freeze JS objects. Once it is frozen, it cannot be unfrozen or altered. The second, fixed view, creates a view that third parties cannot change. They are given only one view into the ArrayBuffer.
• Outcome: Advanced to stage 1.

Change Array by copy for Stage 1

• Notes
• Proposal Link
• Slides
• Summary: Discussed last meeting in the Records and Tuples topic. This proposal will introduce a set of methods which array and tuple will share. The issue with a method like “sort” is that it operates on the array in a mutable way. This proposal introduces a new api, “sorted” which will copy the array and modify it, rather than modifying it in place. The full set of apis is still being determined.
• Outcome: Advanced to stage 1.

Object.has for Stage 1

• 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")
    }
  

• Outcome: Advanced to stage 2.

Stage 1 Updates

Pattern matching update

• Notes
• Proposal Link
• Slides
• Summary: This update revives the pattern matching proposal, which will allow programmers to do complex matches on objects and other types. The proposal has been taken over by a new champion group. The goal is to introduce a useful alternative to switch, with more matching.