tc39/proposal-extractors

Extractors for ECMAScript

Extractors for ECMAScript

A proposal to introduce Extractors (a.k.a. "Extractor Objects") to ECMAScript.

Extractors would augment the syntax for BindingPattern and AssignmentPattern to allow for new destructuring forms, as in the following example:

// binding patterns
const Foo(y) = x;           // instance-array destructuring
const Foo([y]) = x;         // nested array destructuring
const Foo({y}) = x;         // nested object destructuring
const [Foo(y)] = x;         // nesting
const { z: Foo(y) } = x;    // ..
const Foo(Bar(y)) = x;      // ..
const X.Foo(y) = x;         // qualified names (i.e., a.b.c)

// assignment patterns
Foo(y) = x;                 // instance-array destructuring
Foo([y]) = x;               // nestedarray destructuring
Foo({y}) = x;               // nested object destructuring
[Foo(y)] = x;               // nesting
({ z: Foo(y) } = x);        // ..
Foo(Bar(y)) = x;            // ..
X.Foo(y) = x;               // qualified names (i.e., a.b.c)

In addition, this would leverage the new Symbol.matcher built-in symbol added by the Pattern Matching proposal. When destructuring using the new form, the Symbol.matcher method would be called and its result would be destructured instead.

Status

Stage: 1
Champion: Ron Buckton (@rbuckton)

For more information see the TC39 proposal process.

Authors

• Ron Buckton (@rbuckton)

Motivations

ECMAScript currently has no mechanism for executing user-defined logic during destructuring, which means that operations related to data validation and transformation may require multiple statements:

function toInstant(value) {
  if (value instanceof Temporal.Instant) {
    return value;
  } else if (value instanceof Date) {
    return Temporal.Instant.fromEpochMilliseconds(+value);
  } else if (typeof value === "string") {
    return Temporal.Instant.from(value);
  } else {
    throw new TypeError();
  }
}

class Book {
  constructor({
    isbn,
    title,
    createdAt = Temporal.Now.instant(),
    modifiedAt = createdAt
  }) {
    this.isbn = isbn;
    this.title = title;
    this.createdAt = toInstant(createdAt);
    // some effort duplicated if `modifiedAt` was `undefined`
    this.modifiedAt = toInstant(modifiedAt);
  }
}

new Book({ isbn: "...", title: "...", createdAt: Temporal.Instant.from("...") });
new Book({ isbn: "...", title: "...", createdAt: new Date() });
new Book({ isbn: "...", title: "...", createdAt: "..." });

With Extractors, such validation and transformation logic can be encapsulated and reused inside of the binding pattern:

const InstantExtractor = {
  [Symbol.matcher]: value =>
    value instanceof Temporal.Instant ? { matched: true, value: [value] } :
    value instanceof Date ? { matched: true, value: [Temporal.Instant.fromEpochMilliseconds(value.getTime())] } :
    typeof value === "string" ? { matched: true, value: [Temporal.Instant.from(value)] } :
    { matched: false };
  }
};

class Book {
  constructor({
    isbn,
    title,
    // Extract `createdAt` as an Instant
    createdAt: InstantExtractor(createdAt) = Temporal.Now.instant(),
    modifiedAt: InstantExtractor(modifiedAt) = createdAt
  }) {
    this.isbn = isbn;
    this.title = title;
    this.createdAt = createdAt;
    this.modifiedAt = modifiedAt;
  }
}

new Book({ isbn: "...", title: "...", createdAt: Temporal.Instant.from("...") });
new Book({ isbn: "...", title: "...", createdAt: new Date() });
new Book({ isbn: "...", title: "...", createdAt: "..." });

This would also be extremely useful when paired with a forthcoming enum proposal with support for Algebraic Data Types (ADT):

// Rust-like enum of algebraic data types:
enum Option of ADT {
  Some(value),
  None
}

// construction
const x = Option.Some(1);

// destructuring
const Option.Some(y) = x;
y; // 1

// pattern matching
match (x) {
  when Option.Some(y): console.log(y); // 1
  when Option.None: console.log("none");
}

// Another ADT enum example:
enum Message of ADT {
  Quit,
  Move({x, y}),
  Write(message),
  ChangeColor(r, g, b),
}

// construction
const msg1 = Message.Move({ x: 10, y: 10 });
const msg2 = Message.Write("Hello");
const msg3 = Message.ChangeColor(0x00, 0xff, 0xff);

// destructuring
const Message.Move({ x, y }) = msg1;    // x: 10, y: 10
const Message.Write(message) = msg2;    // message: "Hello"
const Message.ChangeColor(r, g, b) = msg3;     // r: 0, g: 255, b: 255

// pattern matching
match (msg) {
  when Message.Move({ x, y }): ...;
  when Message.Write(message): ...;
  when Message.ChangeColor(r, g, b): ...;
  when Message.Quit: ...;
}

Proposed Solution

Extractors are loosely based on Scala's Extractor Objects and Rust's Pattern Matching. Extractors extend the syntax for BindingPattern and AssignmentPattern to allow for the evaluation of user-defined logic for validation and transformation.

Extractors perform array destructuring on a successful match result, starting with a reference to a value in scope using a QualifiedName, which is essentially an IdentifierReference (i.e., Point, InstantExtractor, etc.) or a dotted-name (i.e., Option.Some, Message.Move, etc.).

When an Extractor is evaluated during destructuring, its QualifiedName is evaluated, and that evaluated result's [Symbol.matcher]() method is invoked with the current value to be destructured, returning a Match Result object like { matched: boolean, value: object }.

If matched is true, the value property is further destructured based on the type of Extractor that was defined. If matched is false, a TypeError is thrown.

An Extractor consists of a QualifiedName followed by a parenthesized list of additional destructuring patterns:

// binding pattern
let Foo(a, { b }, [c]) = ...;

// assignment pattern
Foo(a, { b }, [c]) = ...;

Parentheses (()) are used instead of square brackets ([]) for several reasons:

• Avoids collisions with a ElementAccessExpression when the extractor is part of an assignment pattern:

  Option.Some[value] = opt; // already an element access expression

• Ensures a consistent syntax between binding and assignment patterns:

  let Option.Some(value) = opt;
  Option.Some(value) = opt;

• Allows destructuring (and pattern matching) to mirror construction/application:

  let opt = Option.Some(x);
  let Option.Some(y) = opt;
  
  opt = Option.Some(x);
  Option.Some(y) = opt;

Object Destructuring using Extractors

Extractors do not introduce a novel syntax for object extraction. Instead, an Extractor can return a single element match result containing the object to be further destructured:

// binding pattern
const Message.Move({ x, y }) = ...;

// assignment pattern
(Message.Move({ x, y }) = ...);

Iterable Wrapper Overhead

It's important to note that this has the overhead of allocating an iterable wrapper object to perform further destructuring. If necessary, this overhead could be removed if we consider an alternative representation for a match result that indicates result is the sole extracted value, i.e.:

const Message = {
  Move: class Move {
    #x;
    #y;
    ...
    static [Symbol.match](value) {
      if (value instanceof Message.Move) {
        // 'match: "unary"' indicates that 'value' is the sole extracted value
        return { match: "unary", value: { x: value.#x, y: value.#y } };
      }
      return { match: false };
    }
  }
};

const Message.Move({ x, y }) = ...;

Future Object Extractor Syntax

It is possible that a future property-literal construction syntax that might be used by Algebraic Data Types or other constructors, i.e.:

const enum Message of ADT {
  Move{ x, y },
  Write(text),
  Quit
}

// ADT construction
const msg = Message.Move{ x: 10, y: 20 };

// property-literal construction potentially used by fixed-shape objects (i.e., "struct"),
// or a user-defined construction mechanism similar to tagged templates or via a built-in-symbol named method:
struct Point { x, y };
const pt = Point{ x: 10, y: 20 };

However, such a syntax is currently out of scope for this proposal. In addition, introducing an Identifier { syntax for extractors has the high likelihood of carving off too much syntax space that could be used by other proposals. As a result, an "Object Extractor" like syntax like const Point{ x, y } = p is not being considered part of this proposal at this time.

Prior Art

• Scala Extractor Objects
• C# 8.0 Deconstruct
• F# Active Patterns
• Rust Enums
• Rust Pattern Matching

Related Proposals

• Collection Literals (Withdrawn)
• Pattern Matching (Stage 1)
• Enums and Algebraic Data Types (Stage 0, not yet accepted)

Examples

The examples in this section use a desugaring to explain the underlying semantics, given the following helper:

function %InvokeCustomMatcher%(val, matchable) {
    // see https://tc39.es/proposal-pattern-matching/#sec-custom-matcher
}

function %InvokeCustomMatcherOrThrow%(val, matchable) {
  const result = %InvokeCustomMatcher%(val, matchable);
  if (result === ~not-matched~) {
    throw new TypeError();
  }
  return result;
}

Extractor Destructuring

The statement

const Foo(y) = x;

is approximately the same as the following transposed representation

const [y] = %InvokeCustomMatcherOrThrow%(Foo, x);

The statement

const Foo({y}) = x;

is approximately the same as the following transposed representation

const [{y}] = %InvokeCustomMatcherOrThrow%(Foo, x);

Nested Extractor Destructuring

The statement

const Foo(Bar(y)) = x;

is approximately the same as the following transposed representation

const [_a] = %InvokeCustomMatcherOrThrow%(Foo, x);
const [y] = %InvokeCustomMatcherOrThrow%(Bar, _a);

Custom Logic During Destructuring

Given the following definition

const MapExtractor = {
  [Symbol.matcher](map) {
    const obj = {};
    for (const [key, value] of map) {
      obj[typeof key === "symbol" ? key : `${key}`] = value;
    }
    return { matched: true, value: [obj] };
  }
};

const obj = {
    map: new Map([["a", 1], ["b", 2]])
};

The statement

const { map: MapExtractor({ a, b }) } = obj;

is approximately the same as the following transposed representation

const { map: _temp } = obj;
const [{ a, b }] = %InvokeCustomMatcherOrThrow%(MapExtractor, _temp);

Regular Expressions

// potentially built-in as part of Pattern Matching
RegExp.prototype[Symbol.matcher] = function (value) {
  const match = this.exec(value);
  if (match === null) return { matched: false };

  return {
    matched: true,
    value: match
  }
};

const IsoDate = /^(?<year>\d{4})-(?<month>\d{2})-(?<day>\d{2})$/;
const IsoTime = /^(?<hours>\d{2}):(?<minutes>\d{2}):(?<seconds>\d{2})$/;
const IsoDateTime = /^(?<date>[^TZ]+)T(?<time>[^Z]+)Z/;

// match `input`, extract, and destructure (or throw if match fails) using...

// ...a nested-object extractor
const IsoDate({ groups: { year, month, day } }) = input;

// ...a nested-array extractor
const IsoDate([, year, month, day]) = input;

// concise, multi-step extraction using nested destructuring:
const IsoDateTime({
  groups: {
    date: IsoDate({ groups: { year, month, day } }),
    time: IsoTime({ groups: { hours, minutes, seconds }})
  }
}) = input;
// 1. Matches `input` via `IsoDatTime` RegExp and extracts `date` and `time`
// 2. Matches `date` via `IsoDate` RegExp and extracts `year`, `month`, and `day` as lexical bindings
// 3. Matches `time` vai `IsoTime` RegExp and extracts `hours`, `minutes`, and `seconds` as lexical bindings

Potential Grammar

The grammar definition in this section is very early and subject to change.

+   QualifiedName[Yield, Await] :
+       IdentifierReference[?Yield, ?Await]
+       QualifiedName[?Yield, ?Await] `.` IdentifierName

    BindingPattern[Yield, Await] :
        ObjectBindingPattern[?Yield, ?Await]
        ArrayBindingPattern[?Yield, ?Await]
+       QualifiedName[?Yield, ?Await] ExtractorBindingPattern[?Yield, ?Await]

+   ExtractorBindingPattern[Yield, Await] :
+       `(` Elision? BindingRestElement[?Yield, ?Await]? `)`
+       `(` BindingElementList[?Yield, ?Await] `)`
+       `(` BindingElementList[?Yield, ?Await] `,` Elision? BindingRestElement[?Yield, ?Await]? `)`

    AssignmentPattern[Yield, Await] :
        ObjectAssignmentPattern[?Yield, ?Await]
        ArrayAssignmentPattern[?Yield, ?Await]
+       QualifiedName[?Yield, ?Await] ExtractorAssignmentPattern[?Yield, ?Await]

+   ExtractorAssignmentPattern[Yield, Await] :
+       `(` Elision? AssignmentRestElement[?Yield, ?Await]? `)`
+       `(` AssignmentElementList[?Yield, ?Await] `)`
+       `(` AssignmentElementList[?Yield, ?Await] `,` Elision? AssignmentRestElement[?Yield, ?Await]? `)`

+   FunctionCall[Yield, Await] :
+       CallExpression[?Yield, ?Await] Arguments[?Yield, ?Await]

    CallExpression[Yield, Await] :
        CoverCallExpressionAndAsyncArrowHead[?Yield, ?Await]
        SuperCall[?Yield, ?Await]
        ImportCall[?Yield, ?Await]
+       FunctionCall[?Yield, ?Await]
-       CallExpression[?Yield, ?Await] Arguments[?Yield, ?Await]
        CallExpression[?Yield, ?Await] `[` Expression[+In, ?Yield, ?Await] `]`
        CallExpression[?Yield, ?Await] `.` IdentifierName
        CallExpression[?Yield, ?Await] TemplateLiteral[?Yield, ?Await, +Tagged]
        CallExpression[?Yield, ?Await] `.` PrivateIdentifier

Potential Semantics

The semantics in this section are very early and subject to change.

8.5.2 — Runtime Semantics: BindingInitialization

The syntax-directed operation BindingInitialization takes arguments value and environment.

+   BindingPattern : QualifiedName ExtractorBindingPattern

1. Let ref be the result of evaluating QualifiedName.
2. Let extractor be ? GetValue(ref).
3. Let obj be ? InvokeCustomMatcherOrThrow(extractor, value).
4. Let iteratorRecord be ? GetIterator(obj).
5. Let result be IteratorBindingInitialization of ExtractorBindingPattern with arguments iteratorRecord and environment.
6. If iteratorRecord.[[Done]] is false, return ? IteratorClose(iteratorRecord, result).
7. Return result.

8.5.2.2 — Runtime Semantics: InvokeCustomMatcherOrThrow ( val, matchable )

1. Let result be ? InvokeCustomMatcher(val, matchable).
2. If result is not-matched, throw a TypeError exception.
3. Return result.

8.5.3 — Runtime Semantics: IteratorBindingInitialization

The syntax-directed operation IteratorBindingInitialization takes arguments iteratorRecord and environment.

    ArrayBindingPattern : `[` `]`
+   ExtractorBindingPattern : `(` `)`

1. Return NormalCompletion(empty).

    ArrayBindingPattern : `[` Elision `]`
+   ExtractorBindingPattern : `(` Elision `)`

1. Return the result of performing IteratorDestructuringAssignmentEvaluation of Elision with iteratorRecord as the argument.

    ArrayBindingPattern : `[` Elision? BindingRestElement `]`
+   ExtractorBindingPattern : `(` Elision? BindingRestElement `)`

1. If Elision is present, then
   1. Perform ? IteratorDestructuringAssignmentEvaluation of Elision with iteratorRecord as the argument.
2. Return the result of performing IteratorBindingInitialization for BindingRestElement with iteratorRecord and environment as arguments.

    ArrayBindingPattern : `[` BindingElementList `,` Elision `]`
+   ExtractorBindingPattern : `(` BindingElementList `,` Elision `)`

1. Perform ? IteratorBindingInitialization for BindingElementList with iteratorRecord and environment as arguments.
2. Return the result of performing IteratorDestructuringAssignmentEvaluation of Elision with iteratorRecord as the argument.

    ArrayBindingPattern : `[` BindingElementList `,` Elision? BindingRestElement `]`
+   ExtractorBindingPattern : `(` BindingElementList `,` Elision? BindingRestElement `)`

1. Perform ? IteratorBindingInitialization for BindingElementList with iteratorRecord and environment as arguments.
2. If Elision is present, then
   1. Perform ? IteratorDestructuringAssignmentEvaluation of Elision with iteratorRecord as the argument.
3. Return the result of performing IteratorBindingInitialization for BindingRestElement with iteratorRecord and environment as arguments.

13.15.1 — Static Semantics: Early Errors

    AssignmentExpression : LeftHandSideExpression = AssignmentExpression

If LeftHandSideExpression is an ObjectLiteral or, an ArrayLiteral, or a FunctionCall the following Early Error rules are applied:

• It is a Syntax Error if LeftHandSideExpression is not covering an AssignmentPattern.
• All Early Error rules for AssignmentPattern and its derived productions also apply to the AssignmentPattern that is covered by LeftHandSideExpression.

If LeftHandSideExpression is neither an ObjectLiteral, nor an ArrayLiteral, nor a FunctionCall, the following Early Error rule is applied:

• It is a Syntax Error if AssignmentTargetType of LeftHandSideExpression is not simple.

    AssignmentExpression :
        LeftHandSideExpression AssignmentOperator AssignmentExpression
        LeftHandSideExpression `&&=` AssignmentExpression
        LeftHandSideExpression `||=` AssignmentExpression
        LeftHandSideExpression `??=` AssignmentExpression

• It is a Syntax Error if AssignmentTargetType of LeftHandSideExpression is not simple.

13.15.2 — Runtime Semantics: Evaluation

    AssignmentExpression : LeftHandSideExpression `=` AssignmentExpression

1. If LeftHandSideExpression is neither an ObjectLiteral, nor an ArrayLiteral, nor a FunctionCall, then
   1. Let lref be the result of evaluating LeftHandSideExpression.
   2. ReturnIfAbrupt(lref).
   3. If IsAnonymousFunctionDefinition(AssignmentExpression) and IsIdentifierRef of LeftHandSideExpression are both true, then
      1. Let rval be NamedEvaluation of AssignmentExpression with argument lref.[[ReferencedName]].
   4. Else,
      1. Let rref be the result of evaluating AssignmentExpression.
      2. Let rval be ? GetValue(rref).
   5. Perform ? PutValue(lref, rval).
   6. Return rval.
2. Let assignmentPattern be the AssignmentPattern that is covered by LeftHandSideExpression.
3. Let rref be the result of evaluating AssignmentExpression.
4. Let rval be ? GetValue(rref).
5. Perform ? DestructuringAssignmentEvaluation of assignmentPattern using rval as the argument.
6. Return rval.

13.15.5.2 — Runtime Semantics: DestructuringAssignmentEvaluation

The syntax-directed operation DestructuringAssignmentEvaluation takes argument value. It is defined piecewise over the following productions:

+   AssignmentPattern : QualifiedName ExtractorAssignmentPattern

1. Let ref be the result of evaluating QualifiedName.
2. Let extractor be ? GetValue(ref).
3. Let obj be ? InvokeCustomMatcherOrThrow(extractor, value).
4. Return the result of performing DestructuringAssignmentEvaluation of ExtractorAssignmentPattern with argument obj.

    ArrayAssignmentPattern : `[` `]`
+   ExtractorAssignmentPattern : `(` `)`

1. Let iteratorRecord be ? GetIterator(value).
2. Return ? IteratorClose(iteratorRecord, NormalCompletion(empty)).

    ArrayAssignmentPattern : `[` Elision `]`
+   ExtractorAssignmentPattern : `(` Elision `)`

1. Let iteratorRecord be ? GetIterator(value).
2. Let result be IteratorDestructuringAssignmentEvaluation of Elision with argument iteratorRecord.
3. If iteratorRecord.[[Done]] is false, return ? IteratorClose(iteratorRecord, result).
4. Return result.

    ArrayAssignmentPattern : `[` Elision? AssignmentRestElement `]`
+   ExtractorAssignmentPattern : `(` Elision? AssignmentRestElement `)`

1. Let iteratorRecord be ? GetIterator(value).
2. If Elision is present, then
   1. Let status be IteratorDestructuringAssignmentEvaluation of Elision with argument iteratorRecord.
   2. If status is an abrupt completion, then
      1. Assert: iteratorRecord.[[Done]] is true.
      2. Return Completion(status).
3. Let result be IteratorDestructuringAssignmentEvaluation of AssignmentRestElement with argument iteratorRecord.
4. If iteratorRecord.[[Done]] is false, return ? IteratorClose(iteratorRecord, result).
5. Return result.

    ArrayAssignmentPattern : `[` AssignmentElementList `]`
+   ExtractorAssignmentPattern : `(` AssignmentElementList `)`

1. Let iteratorRecord be ? GetIterator(value).
2. Let result be IteratorDestructuringAssignmentEvaluation of AssignmentElementList with argument iteratorRecord.
3. If iteratorRecord.[[Done]] is false, return ? IteratorClose(iteratorRecord, result).
4. Return result.

    ArrayAssignmentPattern : `[` AssignmentElementList `,` Elision? AssignmentRestElement? `]`
+   ExtractorAssignmentPattern : `(` AssignmentElementList `,` Elision? AssignmentRestElement? `)`

1. Let iteratorRecord be ? GetIterator(value).
2. Let status be IteratorDestructuringAssignmentEvaluation of AssignmentElementList with argument iteratorRecord.
3. If status is an abrupt completion, then
   1. If iteratorRecord.[[Done]] is false, return ? IteratorClose(iteratorRecord, status).
   2. Return Completion(status).
4. If Elision is present, then
   1. Set status to the result of performing IteratorDestructuringAssignmentEvaluation of Elision with iteratorRecord as the argument.
   2. If status is an abrupt completion, then
      1. Assert: iteratorRecord.[[Done]] is true.
      2. Return Completion(status).
5. If AssignmentRestElement is present, then
   1. Set status to the result of performing IteratorDestructuringAssignmentEvaluation of AssignmentRestElement with iteratorRecord as the argument.
6. If iteratorRecord.[[Done]] is false, return ? IteratorClose(iteratorRecord, status).
7. Return Completion(status).

API

This proposal would adopt (and continue to align with) the behavior of Custom Matchers from the Pattern Matching proposal:

• A Custom Matcher is a regular ECMAScript Object value with a [Symbol.matcher] method that accepts a single argument and returns a Match Result.
• A Match Result is a regular ECMAScript Object value with a matched property whose value is a Boolean, and a value property whose value will be destructured by the relevant Extractor pattern.
• Symbol.matcher is a built-in Symbol value.

Relation to Pattern Matching

We believe that Extractors would also be extremely valuable as part of the Pattern Matching Proposal, and intend to discuss adoption with the champions should this proposal be adopted.

Extractors could easily be added to MatchPattern using the same syntax as proposed for destructuring, which would allow for more concise and potentially more readily understood code:

match (opt) {
  // without extractors
  when (${Option.Some} with [value]): ...;

  // with extractors
  when (Option.Some(value)): ...;
}

match (msg) {
  // without extractors
  when (${Message.Move} with { x, y }): ...;

  // with extractors
  when (Message.Move({ x, y })): ...;
}

This is even more evident with respect to complex, nested patterns:

match (opt) {
  // without extractors
  when (${Option.Some} with [${Message.Move} with { x, y }]): ...;
  when (${Option.Some} with [${Message.Write} with [text]]): ...;

  // with extractors
  when (Option.Some(Message.Move({ x, y }))): ...;
  when (Option.Some(Message.Write(text))): ...;
}

Relation to Enums and Algebraic Data Types

We strongly believe that ECMAScript will eventually adopt some form of the current enum proposal, given the particular value that Algebraic Data Types could provide. The Enum proposal would strongly favor consistent and coherent syntax between declaration, construction, destructuring, and pattern matching, as in the following example:

enum Message of ADT {
  Quit,
  Move({x, y}),
  Write(message),
  ChangeColor(r, g, b),
}

// construction
const msg1 = Message.Move({ x: 10, y: 10 });
const msg2 = Message.Write("Hello");
const msg3 = Message.ChangeColor(0x00, 0xff, 0xff);

// destructuring
const Message.Move({x, y}) = msg1;      // x: 10, y: 10
const Message.Write(message) = msg2;    // message: "Hello"
const Message.ChangeColor(r, g, b);     // r: 0, g: 255, b: 255

// pattern matching
match (msg) {
  when Message.Move({x, y}): ...;
  when Message.Write(message): ...;
  when Message.ChangeColor(r, g, b): ...;
  when Message.Quit: ...;
}

Here, declaration, construction, destructuring, and pattern matching are consistent for ADT enum members and values:

enum Message of ADT { Move({ x, y }) }      // declaration
const msg =   Message.Move({ x, y });       // construction
const         Message.Move({ x, y }) = msg; // destructuring
match (msg) {
  when        Message.Move({ x, y }): ...;  // pattern matching
}

enum Message of ADT { Write(message) }      // declaration
const msg =   Message.Write(message);       // construction
const         Message.Write(message) = msg; // destructuring
match (msg) {
  when        Message.Write(message): ...;  // pattern matching
}

As noted before, it is possible that a future property-literal construction syntax that might be used by Algebraic Data Types or other constructors. Adding a matching syntax for object extraction would be the responsibility of that proposal and is out of scope for this proposal.

TODO

The following is a high-level list of tasks to progress through each stage of the TC39 proposal process:

Stage 1 Entrance Criteria

• Identified a "champion" who will advance the addition.
• Prose outlining the problem or need and the general shape of a solution.
• Illustrative examples of usage.
• High-level API.

Stage 2 Entrance Criteria

• Initial specification text.
• Transpiler support (Optional).

Stage 3 Entrance Criteria

• Complete specification text.
• Designated reviewers have signed off on the current spec text.
• The ECMAScript editor has signed off on the current spec text.

Stage 4 Entrance Criteria

• Test262 acceptance tests have been written for mainline usage scenarios and merged.
• Two compatible implementations which pass the acceptance tests: [1], [2].
• A pull request has been sent to tc39/ecma262 with the integrated spec text.
• The ECMAScript editor has signed off on the pull request.