Use early error to avoid ASI for +,-,/, and /=

[rbuckton]

This removes +, -, and / from the ThrowExpressionInvalidPunctuator list and instead bans those trailing tokens via static semantics rules to avoid ambiguity as a result of ASI for prefix-+, prefix--, and regular expressions. To verify that a ThrowExpression is not contained on the left side of AdditiveExpression and MultiplicativeExpression, we use a new SDO called ContainsThrowOnRight, which is used to check whether the right-most expression of the left-hand side of those expressions are ThrowExpression. This SDO is intended to handle the case of a ThrowExpression nessted on the right-hand side of an ExponentiationExpression:

a ** throw b 
+ c

As it is necessary to traverse the left side of the + operator (a ** throw b), and look for the right-hand side of the ** operator.

This also removes assignment operators from ThrowExpressionInvalidPunctuator as they were already illegal in the grammar.

Finally, this adds AssignmentExpression : ThrowExpresion /= AssignmentExpression so that we can produce an early error to avoid ASI as well.

This PR utilizes similar Static Semantics rules as those employed by OptionalChain to avoid ASI in cases like this:

a?.b
`c`

Fixes #19

[github-actions]

A preview of this PR can be found at https://tc39.es/proposal-throw-expressions/pr/18.

[rbuckton]

/cc @bakkot, @waldemarhorwat

[nicolo-ribaudo]

I think this addresses the ASI concerns without needing too much early errors scattered all around :)

[nicolo-ribaudo]

Can we assert that the operator is /? Given the the others are impossible due to the lookahead restriction.

[rbuckton]

Sure, I'll fix that shortly.

[nicolo-ribaudo]

Instead of "maintain consistency" I would say "avoid different valid behaviour", given that we are not consistent with statements because we entirely disallow this case.

[rbuckton]

Possibly, though I'd like an editor to weigh in as I think "maintain consistency" here and in OptionalChain TemplateExpression refers specifically to ASI handling, since both grammars are intended to produce an error.

[rbuckton]

This approach did not achieve consensus.

[rbuckton]

I've been asked to leave this open for further discussion.

[ethanresnick]

@rbuckton Before you re-opened this PR, you had said:

Unfortunately, the approach leveraging syntactic restrictions was blocked from advancement. I'm not thrilled with this change either, but it's likely the only way this proposal will ever advance as I don't expect the sentiment towards the trailing syntactic restriction is likely to change.

Does re-opening this PR mean you think that some sort of syntax restrictions might be a viable solution after all?

Personally, as a developer (i.e., not a spec author or implementer), I just want to be able to avoid parentheses in the overwhelmingly-common cases of throw new Error() and throw makeSomeError(...). In all the more obscure cases, I think the optimal DX is to require parentheses around the value on the right of the throw, and provide a good error message if parentheses are omitted.

If parentheses are required in the common case, where there isn't any ambiguity, that will feel like an arbitrary, annoying restriction to almost every developer who encounters it, as they won't be steeped in the arcane details of the grammar.

One comment from the meeting notes was:

WH: I do not want early errors. This should be purely grammatical. It’s much easier to understand purely grammatical syntax than rules expressed as early errors.

I'm not totally unsympathetic to that sentiment — I get that set of possible source texts is giant and that the spec authors have to be able to reason about it to keep the language extensible and possibly even to avoid security issues.

But, purely as a developer, this sort of distinction (grammatical restriction vs early error), is not something I care about at all (or perhaps I'd even prefer an early error, if the error message can be more useful). So, I'd hope it doesn't result in parentheses being required everywhere.