Normative changes to decorator "extra initializer" evaluation order

[rbuckton]

Acknowledgement

• I acknowledge that issues using this template may be closed without further explanation at the maintainer's discretion.

Comment

Per https://github.com/pzuraq/ecma262/pull/12/files, which achieved consensus in the November 2023 TC39 meeting, the "extra initializers" for fields/auto-accessors (added by context.addInitializer) now need to be run independently for each field, immediately after the field itself is initialized and defined on the class instance.

This results in the need to change our emit for Stage 3 decorators as follows:

Given:

class C {
  @dec a;
  @dec b;
  @dec f() { }
}

We currently emit (some parts elided):

let C = (() => {
  ...
  return class C {
    static {
      ...
      __esDecorate(null, null, _f_decorators, { ... }, null, _instanceExtraInitializers);
      __esDecorate(null, null, _a_decorators, { ... }, _a_initializers, _instanceExtraInitializers);
      __esDecorate(null, null, _b_decorators, { ... }, _b_initializers, _instanceExtraInitializers);
      ...
    }
    a = (__runInitializers(this, _instanceExtraInitializers), __runInitializers(this, _a_initializers, void 0));
    b = __runInitializers(this, _b_initializers, void 0);
    f() { }
  };
})();

Here, we collect all "instance extra initializers" in a single array and evaluate them immediately after the this value is bound in the constructor (i.e. immediately upon entry to the constructor in a base class, or immediately after super() is called in a derived class). When fields are present, we evaluate the extra initializers as part of evaluating the initializer for the first field of the class.

After this change, we need to emit something like this instead:

let C = (() => {
  ...
  let _a_extraInitializers = [];
  let _b_extraInitializers = [];
  return class C {
    static {
      __esDecorate(null, null, _f_decorators, { ... }, null, _instanceExtraInitializers);
      __esDecorate(null, null, _a_decorators, { ... }, _a_initializers, _a_extraInitializers);
      __esDecorate(null, null, _b_decorators, { ... }, _b_initializers, _b_extraInitializers);
    }
    constructor() {
      __runInitializers(this, _b_extraInitializers);
    }
    a = (__runInitializers(this, _instanceExtraInitializers), __runInitializers(this, _a_initializers, void 0));
    b = (__runInitializers(this, _a_extraInitializers), __runInitializers(this, _b_initializers, void 0));
    f() { }
  };
})();

Here, we still run the extra initializers for methods/getters/setters first, but we run the extra initializers for a after it is defined on the instance, but before we initialize b, and run the initializers for b at the top of the constructor, which is evaluated after b has been defined on the instance.

[fatcerberus]

What are "extra initializers"? In the example code given there is no initialization at all as far as I can tell.

[rbuckton]

In the example code, a and b are initialized to undefined (i.e., void 0), which you can see in the fragment __runInitializers(this, _a_initializers, void 0). These are "normal" initializers, which decorators can hook:

function dec(target, context) {
  if (context.kind === "field") {
    return function (value) { return value; }; // injects a transformation into "normal" initialization.
  }
}

Extra initializers are added by a decorator via context.addInitializer, and are primarily meant to perform some kind of registration using the instance:

function dec(target, context) {
  context.addInitializer(function() {
    registerThisInstance(this);
  });
}

[rbuckton]

Here's an example of the difference in timing:

class C {
  @dec a = 1;
}
function dec(target, context) {
  context.addInitializer(function() {
    this.a; // before: undefined
            // after: 2
  });
  return function (value) {
    this.a; // before/after: undefined
    value; // 1
    return value + 1;
  };
}