Missing early error restriction for accessors with different placement, but same private name

[anba]

There is currently no early error restriction for:

class C {
  static get #a() {}
  set #a(v) {}
}

[littledan]

Oops, that certainly needs to be fixed. Does anyone want to write a PR? Or otherwise, I will try to get to this in the coming weeks.

[caiolima]

Should this be an early error SyntaxError, right?

[littledan]

The use of runtime, rather than early, errors for these cases was deliberate in this proposal. My apologies for not documenting this better. My preference is to stick with runtime errors for these sorts of cases, to enable flexibility in the design space for decorators.

When I think about early errors in JavaScript, I think about errors that we can give reliably, under all circumstances. As an example, ES6 removed the strict mode prohibition on duplicate property keys in object literals, because computed property names made that check impossible to do consistently.

We've been careful to not give the decorators proposal the ability to subvert important properties of private names. For example, a decorator cannot introduce a new private name to the class scope (although there were several requests)--the private name scope is purely lexical, and requires the use of a declaration that's lexically present.

However, within the frame of lexical scoping, there's potential flexibility for how private fields and methods are used. The 2018-Jan 2019 decorators proposal included the capability of decorators to turn a private field into a private accessor or private method, or vice versa. This is useful, for example, if you want to observe writes to a private field. You could also picture a @nonwritable decorator applied to a private field. To enable this, the writability of a private field or method is a runtime, not static, attribute.

In this context, it's only possible to do the appropriate checks at early error time if no decorator is used, which would be an unusual discontinuity. The newer "static decorators" proposal does not include these capabilities in decorators. However, I'd like to leave the door open for a potential future built-in decorator to add this capability. Note that, even with static decorators, we still don't know what the decorator does at "early error time", since we don't have access to imports at that time.

[littledan]

I hid the above comment, since I posted it to the wrong issue.