Waldemar made a comment showing his concerns at https://github.com/tc39/proposal-pipeline-operator/issues/91#issuecomment-1084946624. They’re about distinguishing decorators from topic-then-infix-operators-that-are-also-valid-identifiers (examples he gave are of and as).

Thankfully, as far as I can tell, they are not a problem; the example he gave already has a SyntaxError (the LHS of of in for statements can only be identifiers or destructuring forms, not @).

The biggest issue is with any future infix operators that are also valid identifiers (like as), and we can just keep @ as class {} and @ as function () {} as decorator expressions, and we can require parentheses to distinguish them from @ as (class {}) and @ as (function () {}) using lookahead. There’s an example grammar in https://github.com/tc39/proposal-pipeline-operator/issues/91#issuecomment-1085006912.

jschoi: I think @in x is currently valid and it would be quite surprising if it wasn't! The lexical grammar in the spec (ignoring oddities like regexps) eagerly consumes the tokens as long as they match, so @in x is tokenized as @,in,x. Then the syntactic grammar sees @,in and x, without any whitespace knowledge.

There are only two places where witespaces matter:

• in private identifiers, because #foo is parsed as a single token
• between an identifier and a keyword, because the tokenizer is eager and would parse it as a single identifier