Class decorators don't respect field declarations order

[nicolo-ribaudo]

Suppose we have the following class:

class A {
  foo = alert(1);
  #bar = alert(2);
  baz = alert(3);
}

new A();

It correctly alerts 1, 2, 3

Lets add a class decorator:

function noop() {}

@noop
class A {
  foo = alert(1);
  #bar = alert(2);
  baz = alert(3);
}

new A();

Now it alerts 1, 3, 2.

This is because DecorateConstructor recreates the list of element descriptors by joining a list containing only the public elements with a list containing only the private elements.

We can fix this problem in two ways:

1. Always run public initializers first, and then private initializers. This is the easiest way but it can be confusing.
2. Add some kind of "placeholders" in the elements array, so that class decorators can't read or modify them but they can be kept in the correct order. The noop would then take a parameter similar to

{
  kind: "class",
  elements: [
    {
      kind: "field",
      placement: "own",
      key: "foo",
      initializer() { alert(1); }
    },
    PrivateElementPlaceholder { [[PrivateName]]: #bar },
    {
      kind: "field",
      placement: "own",
      key: "baz",
      initializer() { alert(3); }
    }
  ]
}

[littledan]

Good point!

What if we represent private field initializers as "starter" elements?

[nicolo-ribaudo]

By doing so a class decorator would be able to change their placement.

Actually I'm not even sure that we should pass starter/finisher elements to class decorators, since they are too "opaque" to be possible for a decorator to do something useful with them (similarly to #177 (comment)).

[littledan]

Hmm, good point. So those should also be "placeholders" (since starters are interspersed with other initializers)?

[nicolo-ribaudo]

Yes.
Probably an object with { kind: "placeholder" }* and an internal slot pointing to the descriptor would be ok.
And it should probably throw if they are added/removed from elements.

* kind: placeholder/internal/obfuscated?

[littledan]

I like "internal", but further bikeshedding still welcome on this thread. Interested in making a PR for this, @nicolo-ribaudo ?

[littledan]

We considered this change in #184, but realized that it would be really complicated and ultimately insufficient. In the end, we added back in private elements to class elements (#197), and many of us prefer that solution, but if it's unacceptable, we have #203 as a backup plan. In either of those two cases, class decorators respect field evaluation order.