TC39 meeting, July 13-16 2021

In this meeting, the Realms proposal finally moved forward to stage 3. The form it will take is as what is now called “isolated realms”. This form does not allow direct object access across the realm boundary (which you can do with iframes). To address this, a new proposal is being put forward titled getOriginals.

Beyond that, the ergonomic brand checks proposal moved to stage 4 and will be published in the next specification. Intl.Enumeration also finally moved to stage 3 and implementers have started working on it.

A feature that developers can look forward to experimenting with soon is Array find-from-last. This will enable programmers to easily search for an element from the end of a collection, rather than needing to first reverse the collection to do this search.

Keep an eye on…

• Realms
• Import assertions
• Module fragments

Normative Spec Changes

Remove “Designed to be subclassable” note.

• Notes
• Proposal
• Slides
• Summary: Unrelated to the “remove subclassable proposal” – this pr seeks to remove confusing notes about the “subclassabilty” of classes such as “boolean” where such a note makes no sense.
• Impact on SM: No change
• Outcome: Consensus.

Restricting callables to only be able to return normal and throw completions

• Notes
• Proposal
• Slides
• Summary: This proposal tightens the specification language around the return value of callables. Prior to this change, it would be possible for a spec compliant implementation to have functions return with a completion type “break”. This doesn’t make that much sense and is fixed here.
• Impact on SM: No change
• Outcome: Consensus.

Proposals Seeking Advancement to Stage 4

Ergonomic Brand Checks

• Notes
• Proposal
• PR
• Spec
• Summary: Provides an ergonomic way to check the presence of a private field when one of its methods is called.
• Impact on SM: Already Shipping,
  • Bug
• Outcome: Advanced to stage 4.

Proposals Seeking Advancement to Stage 3

Array Find From Last

• Notes
• Proposal Link
• Slides
• Summary: Proposal for .findLast() and .findLastIndex() methods on array.
• Impact on SM: In progress
  • Bug
• Outcome: Advanced to stage 3

Intl Enumeration API

• Notes
• Proposal Link
• Slides
• Summary: Intl enumeration allows inspecting what is available on the Intl API.
• Impact on SM: In progress
  • Bug
• Outcome: Advanced to stage 3.

Realms for stage 3

• Notes Day 1
• Notes Day 3
• Proposal Link
• Slides
• Summary: The Realms proposal 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 previous meeting. In this meeting the issue was resolved by splitting out the added functionality to its own proposal, getOriginals. Realms advanced to stage 3. getOriginals advanced to stage 1.
• Impact on SM: Needs implementation, must not ship until the name “Isolated Realms” has been resolved.
  • Bug
• Outcome: Realms advanced to stage 3. GetOriginals advanced to stage 1.

Stage 3 Updates

Intl.NumberFormat v3

• 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: In progress
  • Bug
• Outcome: Advanced to stage 3.

Extend TimeZoneName Option Proposal

• Notes
• Proposal Link
• Slides
• Summary: Adds further options for the TimeZoneName option in Intl.DateTimeFormat, allowing for greater accuracy in representing different time zones. No major changes since last presentation.
• Impact on SM: Implemented
  • Bug

Intl Locale update

• 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. There was a request regarding excluding standard and search from intl.Locale.prototype.collations, which was retrospectively agreed to.
• Impact on SM: In progress
  • Bug

Intl DisplayNames

• Notes
• Proposal Link
• Slides
• Summary: Adds further coverage to the existing Intl.DisplayNames API. No significant changes since last presentation. There has been progress in implementation.
• Impact on SM: In progress
  • Bug

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. From our perspective it would be better to restrict this somehow – for now the champions will not change the specification.

• Impact on SM: Implementation in Progress
  • Bug

Object.hasOwn (Accessible Object hasOwnProperty)

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

  No significant changes since the last update.

• Impact on SM: Implemented
  • Bug

Proposals Seeking Advancement to Stage 2

Array filtering

• Notes
• Proposal Link
• Slides
• Summary: This proposal was two proposals bundled. It introduces a .filterReject method which is an alias for a negative filter, such as [1, 2, 3].filter(x => !(x > 2)) which would return all of the elements less than or equal to 2. This did not move forward. A second proposal, groupBy, which groups elements related to a condition (for example, [1,2,3].groupBy(x => x > 2), would return {false:[1,2],true: [3]}); GroupBy advanced to stage 1 as a separate proposal.
• Impact on SM: No change yet.
• Outcome: FilterOut did not advance. GroupBy is treated as its own proposal and is now stage 1.

Stage 2 Updates

Decorators update

• Notes
• Proposal Link
• Slides
• Summary: The decorators proposal had a champion switch, but they are now happy with the current semantics of the proposal and are seeking stage 3 proposal reviewers. Decorators are functions called on classes, class elements, or other JavaScript syntax forms during definition. They have 3 capabilities: to replace the value being decorated, to associate metadata with a given value being decorated, or provide access to that decorated value. Our concerns with the proposal were related to possible performance issues arising from the proposal. These were addressed in the last iteration, and we are looking forward to rereading the spec.
• Impact on SM: Needs review.

Proposals Seeking Advancement to Stage 1

ArrayBuffer to/from Base64

• Notes
• Proposal Link
• Slides
• Summary: Transforms an array buffer to and from Base64. base64 is the de-facto standard way to represent arbitrary binary data as ASCII. JavaScript has ArrayBuffers (and other wrapping types) to work with binary data, but no built-in mechanism to encode that data as base64, nor to take base64’d data and produce a corresponding ArrayBuffer. Peter Hoodie from Moddable raised concerns about this being out of scope, but did not block stage 1.
• Impact on SM: No change yet.
• Outcome: Advanced to stage 1.

Stage 1 Updates

Module fragments current direction

• Notes day 2
• Notes day 3
• Proposal Link
• Slides

• Summary: The Module fragments proposal allows multiple modules to be written in the same file. The issue was raised that this proposal should be closer in terms of syntax to module blocks, and this change achieved consensus. The primary changes are:

  • Module fragments are named by identifiers, not strings, so they are declared like module foo { export x = 1 }
  • Import statements can load a module fragment with syntax like import { x } from foo;, similarly as an identifier.
  • Import statements which import from a module fragment can work on anything which was declared by a top-level module fragment declaration in the same module, or one which was imported from another module. There’s a link-time data structure representing the subset of the lexical scope which is the statically visible module fragments.
  • When a declared module fragment is referenced as a variable, in a normal expression context, it evaluates to a module block (one per time when it was evaluated, so the same one is reused for module fragments declared at the top level). It appears as a const declaration (so the link-time and run-time semantics always correspond).
  • Module fragments are only visible from outside the module by importing the containing module, and here, only if they are explicitly exported. They have no particular URL (note related issue: Portability concerns of non-string specifiers #10)
  • Module fragment declarations can appear anywhere a statement can, e.g., eval, nested blocks, etc (but they can only have a static import against them if they are at the top-level of a module). In contexts which are not the top level of a module, module fragments are just useful for their runtime behavior, of a nice way of declaring a module block.

  This achieved consensus and the proposal had support overall.

• Impact on SM: No change yet.