Should @(expr)() be allowed?

[pzuraq]

This is currently allowed in the spec text, and matches the previous parsing behavior of the Babel transform from January 2019 proposal. I'm not sure if this was intentional though, and it seems to not match up with the described syntax:

Decorator expressions are restricted to a chain of variables, property access with . but not [], and calls (). To use an arbitrary expression as a decorator, @(expression) is an escape hatch.

The spec text from that time was not correct, it allowed even more expressive chaining (e.g. @(foo).bar) so I had to make updates to it. It's unclear if this is necessary or could just be another escape case.

[js-choi]

This is a great catch. I would be negatively surprised if @(decoratorExpr)() … would be allowed. In particular, allowing @(decoratorExpr)() … would complicate parsing of function calls on the @ topic reference from the pipe operator (@(arg0); see also tc39/proposal-pipeline-operator#91 (comment)), which is simple to distinguish from @(decoratorExpr) class {} but more difficult to distinguish from @(decoratorExpr)() class {}. I would strongly urge the specification to match the explainer and prohibit @(decoratorExpr)().

[pzuraq]

// Allowed
@foo
@foo()
@foo.bar()
@(foo['bar']('baz'))

// Not allowed
@foo().bar
@(foo).bar
@foo['bar']

// Not sure yet
@(foo['bar'])()
@this.#x()

[Jack-Works]

I think there is no need to support @(expr)().

[pzuraq]

We discussed this further in plenary and decided that @(expr)() will not be allowed. I will be updating the explainer and spec accordingly.

[pzuraq]

This has been updated in the spec, closing this issue