Should we allow PrivateIdentifier in DecoratorMemberExpression?
JLHwung opened this issue · 12 comments
The current syntax
DecoratorMemberExpression[Yield, Await] :
IdentifierReference[?Yield, ?Await]
DecoratorMemberExpression[?Yield, ?Await] . IdentifierName
( Expression[+In, ?Yield, ?Await] )
disallows o.#p as a decorator member expression, instead one would have to parenthesize it into (o.#p).
Yes, this is intentional. Only plain, basic member expressions are allowed in this location, otherwise you have to use parens.
How is accessing a private field not basic?
The only case where this would be possible is in a nested class declaration, e.g:
class Outer {
#dec() {}
inner = class Inner {
@this.#dec()
m() {}
}
}This seems fairly uncommon in real world usage and so extra parens in this case shouldn't be an issue.
class C {
static #dec = function () {};
@C.#dec field = 42;
}
Fair enough, but also a very uncommon situation. We also disallow [] indexing within decorator chaining, and many other "normal" chaining features such as optional chaining.
In other words, the only thing that is allowed explicitly is simple non-dynamic public property access. Anything else much be wrapped in parens.
I could understand the line being drawn around “no computed”, but private fields are very static. What’s the harm in allowing the parens to be omitted there?
Fair enough, I was mainly trying to not re-litigate the previous agreements on syntax here but maybe it's worth reconsidering
I think it’d be a fine follow-on if the change would slow the proposal, but i think it’s worth including.
Yeah, it feels weird to me to carve out private fields (vs public fields), even though I agree they're probably not going to get much use.
We discussed this further in plenary and decided to include private fields here, I will be updating the explainer and spec accordingly.
I don't think #435 (comment) will work either way, because also this is disallowed.
This has been updated in the spec, closing this issue.