[lifthrasiir]

> that new "#private" thing

I can agree that classes have been more or less a syntactic sugar, but private identifiers are not. The field name collision is a problem in virtually every dynamically typed language with namespace inheritance and each language has their solutions (see Python `__mangled_name` and Ruby `@instance_var`), JavaScript just happens to have another solution and that alone justifies a separate `class` syntax (since the scope of such private identifiers should be lexical).

[tnzm]

I know they're not, that's why I'm objecting to them in principle (even though I use them and they're quite handy). JavaScript already has a solution - just put the private fields in the parent closure where they can't be accessed externally. In my example above, x is a private field, and the constructor function Foo can be asynchronous. The new semantics is a kludge around the supposedly "optional" class syntax sugar.

Remember, once upon a time JS was supposed to be Scheme...

[lifthrasiir]

> just put the private fields in the parent closure where they can't be accessed externally

Your approach can't translate the following code:

    class MyNumber {
        #value;
        constructor(value) { this.#value = value; }
        add(other) { return new MyNumber(this.#value + other.#value); }
    }

The proper solution is to use a non-enumerable property with an unnamed Symbol name, which is possible but cumbersome.

[tnzm]

You're not supposed to be able to refer to other.#value, though, isn't that the entire point of a private field?

[lifthrasiir]

They are private to classes, not instances. Many languages with private fields do allow access to private fields in other instances of the same class.