The proposal is at stage 3, with implementation activity in other engines.

I'm super excited for this feature. When do folks think this will be shipped?

This allows to convert two loops to use std::count_if and will also be used
in later patches. Also amend a loop to use continue to decrease the nesting
levels.

The previous approach to handle unnecessary .initializers scopes doesn't seem
to work correctly, because dis(class{constructor(){}}) shows that the scope is
still allocated. When moved into the bytecode emitter, the scope was correctly
omitted.
Also add a more descriptive comment to explain why .initializers is added in
its own scope.

Depends on D53636

• yield is always a name when parsing a class field initialiser, therefore we
  don't need to pass YieldHandling around.
• this is always defined when class initialisers run, therefore we don't need
  to pass HasHeritage around.
• Also change FunctionBox::initFieldInitializer to only set those members
  which are affected by class field initialisers. In all other cases use the
  default state set through initWithEnclosingParseContext.

Depends on D53637

Parser.{h,cpp}:

• Add a new ClassFields struct to count class fields to avoid passing
  another two size_t parameters pair to various functions.

BytecodeEmitter.{h,cpp}:

• Use a separate enum class instead of a plain bool isStatic for readability.

ObjectEmitter.{h,cpp}:

• Add a separate state for class field initialisation to avoid duplicating
  multiple states for instance vs. static class fields.
• Also add an additional state to track when the initialiser expression was
  emitted to ensure emitFieldInitializerHomeObject won't be called out of order.

Depends on D53638

Depends on D53639

Depends on D53640

Class field initialisers didn't call leaveInnerFunction, which means direct
eval flags weren't properly propagated through PropagateTransitiveParseFlags.

Depends on D53641

Test262 doesn't cover these tests.

Depends on D53642

NI to make sure the review request didn't fall through the cracks. :-)

ClassField::initializer() is never null, because when no initialiser
expression is present, we're synthesising a "raw-undefined" node. There were
plans to optimise this case, but because the current code is unfinished, it
makes more sense to remove the handling for ClassField::initializer()
returning null (for now at least).

Decrease the nesting level to improve the readibility a bit.

Depends on D63509

https://hg.mozilla.org/mozilla-central/rev/0b6c1c4cde0b
https://hg.mozilla.org/mozilla-central/rev/da3d3ad76c02
https://hg.mozilla.org/mozilla-central/rev/3aa03a84ae22
https://hg.mozilla.org/mozilla-central/rev/000cc3139baa
https://hg.mozilla.org/mozilla-central/rev/148b48f68f56
https://hg.mozilla.org/mozilla-central/rev/210ed28f7ec4
https://hg.mozilla.org/mozilla-central/rev/2c8e0801719c
https://hg.mozilla.org/mozilla-central/rev/a40744563dc4
https://hg.mozilla.org/mozilla-central/rev/1fd2c781ac64

\o/

Should we send an intent-to-ship?

Does this bug also covers private static class fields? I can't find open bug for them. They also don't seem to work in 75 Nightly.

(In reply to Jan de Mooij [:jandem] from comment #17)

Should we send an intent-to-ship?

I've just send an intent-to-ship. It should be appear on dev-platform after moderator approval has been granted.

(In reply to Sergey Rubanov from comment #18)

Does this bug also covers private static class fields? I can't find open bug for them. They also don't seem to work in 75 Nightly.

No, private class fields (neither instance nor static) aren't yet implemented.

Doc updates

Compat table
https://wiki.developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Classes#Browser_compatibility
(https://github.com/mdn/browser-compat-data/pull/5823)

Reference docs
https://wiki.developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Classes/Class_fields#Public_static_fields

Release notes
https://wiki.developer.mozilla.org/en-US/docs/Mozilla/Firefox/Releases/75#JavaScript