What’s New in TC39? From Error Cause to Intl.DisplayNames v2 and Beyond

At the recent TC39 meeting we advanced the Error Cause proposal to Stage 1, establishing a standardized JavaScript error‑handling pattern for Alibaba tools such as Alinode and ARMS.

Stage 3 → Stage 4

To move a proposal from Stage 3 to Stage 4 it must satisfy three criteria:

Provide a full tc39/test262 test suite covering the proposal.

Have at least two JavaScript engines or transpilers pass the Test262 suite and ship the feature.

Submit a Pull Request to tc39/ecma262 that is signed off by the ECMAScript editors.

Intl.DisplayNames

This Stage 4 proposal adds internationalized names for common nouns such as regions, languages, scripts, and currencies.

Region codes can be ISO‑3166 two‑letter codes or three‑digit UN M49 region codes.

Script codes must be ISO‑15924 four‑character codes.

Language codes follow the UTS 35 grammar (e.g., en, zh-Hans).

Currency codes are three‑letter ISO 4217 codes.

// Simplified Chinese region names
let regionNames = new Intl.DisplayNames(['zh-Hans'], {type: 'region'});
regionNames.of('US');   // "美国"
regionNames.of('419');  // "拉丁美洲"
regionNames.of('MM');   // "缅甸"

The features are already available in Chrome 81 and Node.js 14 without any flags.

.item() for indexables

Proposal: tc39/proposal-item-method (spec: item() )

The proposal introduces an item() method for arrays, typed arrays, strings, and other indexable objects, enabling reverse indexing such as arr.item(-1). It also adds String.prototype.item() with semantics matching "foo"[idx], e.g., '👩‍❤️‍👨'.item(3) === "❤".

Import Assertions

Proposal: tc39/proposal-import-assertions

This proposal adds an assert clause to the import statement, allowing developers to specify the expected module type. Example:

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

The proposal does not define JSON module semantics; those are covered by a separate Stage 2 proposal.

Stage 1 → Stage 2

Advancing to Stage 2 requires a complete draft of the standard text describing the proposal.

Class static initialization block

Proposal: tc39/proposal-class-static-block

Static blocks execute once when a class is evaluated, have access to private fields, and enable patterns such as friend classes.

let A, B;
{
  let friendA;
  A = class A {
    #x;
    static {
      friendA = {
        getX(obj) { return obj.#x; },
        setX(obj, value) { obj.#x = value; }
      };
    }
  };
  B = class B {
    constructor(a) {
      const x = friendA.getX(a); // ok
      friendA.setX(a, value);    // ok
    }
  };
}
export { A, B };

ResizableArrayBuffer and GrowableSharedArrayBuffer

Proposal: tc39/proposal-resizablearraybuffer

These proposals introduce two new buffer types to improve memory handling for WebAssembly. ResizableArrayBuffer can change size in place, while GrowableSharedArrayBuffer can only grow, supporting shared memory across agents.

let rab = new ResizableArrayBuffer(1024, 1024 ** 2);
assert(rab.byteLength === 1024);
assert(rab.maximumByteLength === 1024 ** 2);
rab.resize(rab.byteLength * 2);
assert(rab.byteLength === 2048);

Intl.Enumeration

Proposal: tc39/proposal-intl-enumeration

The API enumerates supported calendars, currencies, number systems, time zones, etc.

// Supported calendars
Intl.getSupportedCalendars(); // ["buddhist", "chinese", "coptic", ...]

Stage 0 → Stage 1

Requirements for a Stage 0 proposal to reach Stage 1:

Find a TC39 champion.

Clearly state the problem, need, and a rough solution.

Provide concrete examples.

Discuss API shape, algorithms, semantics, and implementation risks.

Double‑Ended Iterator & Destructuring

Proposal: tc39/proposal-deiter

Introduces a bidirectional iterator that supports destructuring such as let [first, ...rest, last] = iterable. No consensus was reached at the meeting.

let a = [1, 2, 3, 4, 5, 6];
let deiter = a.values(); // assume a double‑ended iterator
deiter.next();        // {value: 1}
deiter.next();        // {value: 2}
deiter.next('back'); // {value: 6}

Integer and Modulus Math

Proposal: integer-and-modulus-math-proposal

Adds integer‑oriented math methods: Math.mod(x, y) – IEEE‑754 modulus. Math.idiv(x, y) – 32‑bit integer division. Math.imod(x, y) – 32‑bit integer modulus. Math.idivmod(x, y) – returns [quotient, remainder]. Math.imuldiv(x, y, z) – computes (x * y) / z with a 64‑bit intermediate. Math.irem(x, y) – integer remainder.

Standardized Debug

Proposal: tc39/proposal-standardized-debug

Proposes a dbg! macro (or an extension of debugger) to print intermediate values without duplicating expensive computations.

function doSomething(a) {
  let b = dbg!(a + costlyOperation()) * 2;
  // ...
}

String Dedent

Proposal: tc39/proposal-string-dedent

Provides String.dedent to strip common leading whitespace from template literals.

class Foo {
  methodA() {
    const foo = String.dedent(`
      First Line
      Second Line
      Third Line`);
    return foo;
  }
}

Intl Locale

Proposal: tc39/proposal-intl-locale-info

Exposes locale‑specific information such as first day of week, minimal days in first week, weekend start/end, text direction, measurement system, default hour cycle, default calendar, common calendars, etc.

+ get Intl.Locale.prototype.firstDayOfWeek
+ get Intl.Locale.prototype.minimalDaysInFirstWeek
+ get Intl.Locale.prototype.weekendStart
+ get Intl.Locale.prototype.weekendEnd
+ get Intl.Locale.prototype.direction
+ get Intl.Locale.prototype.measurementSystem
+ get Intl.Locale.prototype.defaultHourCycle
+ get Intl.Locale.prototype.defaultCalendar
+ get Intl.Locale.prototype.commonCalendars

Intl.DisplayNames v2

Proposal: tc39/intl-displaynames-v2

Extends Intl.DisplayNames with additional types such as months, weekdays, units, time zones, calendars, and counting systems, allowing calls like:

let dn = new Intl.DisplayNames('zh-Hans', {type: 'month', style: 'long'});
dn.of(1); // "1月"

let dnEn = new Intl.DisplayNames('en', {type: 'month', style: 'long', calendar: 'coptic'});
dnEn.of(1); // "Tout"

Conclusion

Standardizing a language is incremental; many useful proposals stall due to design disagreements, while others evolve through multiple revisions. Active participation from the JavaScript community—raising needs, discussing designs, and contributing code—is essential for the continued evolution of ECMAScript.