Why not require both a keyword and a sigil?

[ExE-Boss]

JavaScript already reserves the private keyword, so we wouldn’t be breaking existing code.

Also, I believe that the intent of the following is clearer:

class X {
    private #foo;

    logFoo() {
        console.log(this.#foo)
    }
}

Also, no browser ships this yet.

[ljharb]

See the FAQ.

[jhpratt]

@ljharb The section you linked is for bare identifiers, not prefixed by a sigil. I'm pretty sure this has been discussed before, but it definitely isn't in the FAQ.

[ExE-Boss]

The thing is that just the # sigil prefix doesn’t feel clear enough without understanding this proposal and the inner workings of ECMAScript.

Doing private #foo is more verbose, but it’s also a lot more obvious what the code does.

[ljharb]

You're right; it's not in the FAQ, my mistake.

I believe the general intuition was that once people learned #, private would feel like annoying unnecessary boilerplate, since # would already mean "private".

[ExE-Boss]

I still prefer private #foo over just #foo.

Maybe make the first valid syntax?

[ljharb]

It would be strictly worse to make the keyword optional - it should either be required or forbidden. Currently, the shipping stage 3 proposal forbids it.

[ExE-Boss]

I’d prefer to make it required then.

[littledan]

We discussed this particular idea at the March 2019 TC39 meeting, in the context of @jridgewell's private name declarations proposal, and we decided not to pursue it further.

[Igmat]

We discussed this particular idea at the March 2019 TC39 meeting, in the context of @jridgewell's private name declarations proposal, and we decided not to pursue it further.

@littledan, I think it was a mistake. Is there are any details why does https://github.com/tc39/proposal-private-declarations/issues/1 was rejected? @jridgewell, unfortunately, didn't provide them.

And as for me private-declarations and class-fields mix in current state will be very surprising for average developer.

[littledan]

The meeting notes are coming out soon. Personally, I don't think it's a good idea to require people to repeat themselves. And in the context of the private declarations proposal, it wouldn't leave space open for protected, as many have asked for. This issue is also a duplicate of several previous discussions where the rationale was explained, so closing it.

[Igmat]

@littledan, there is space for protected as I shown here https://github.com/tc39/proposal-private-declarations/issues/6. And it is actually valid use-case, which was asked few times already in this repo, like #60 and #102 and using protected will be very clear to solve this problem.

Also, I would love to elaborate my position. Following sample seems weird for me:

class A {
  #a = 1;
  method() {
    private #a;
    console.log(this.#a); // what will happen?
    console.log(this[#a]); // what will happen?
    return class B {
      #a = 2;
      [#a] = 2;
      method() {
        console.log(this.#a); // what will happen?
        console.log(this[#a]); // what will happen?
      }
    }
  }
}

I do think that adding keyword to class-fields will solve problem with this strange mix of private-declarations and class-fields, while also adding meaningful and suitable protected.