Strengthen assignment target definitions.

[RReverser]

Reopen of #134 with more precise yet backward-compatible assignment target definitions.

[mikesherov]

👍

[michaelficarra]

Not just CallExpression. Any expression can be in this position in ES5 and below.

[RReverser]

No, see discussion in previous PRs. In ES5 specifications must reject as an early error any LHS that can't evaluate to Reference in runtime, and only CallExpression are such that could result in Reference despite being expressions. For literals, unary, binary and conditional expressions there is no way in spec they can evaluate to Reference and thus must be rejected in such position.

EDIT: On the other thought, perhaps SequenceExpression and ConditionalExpression can evaluate to Reference if their last values are CallExpression and should be allowed too, need to recheck.

EDIT(2): Rechecked, both SequenceExpression and CondtionalExpression perform GetValue on results on subexpressions, so can't be in this position, too.

[michaelficarra]

Ah, I didn't know about that early error in ES5. Okay, then I am fine with this as long as we add an item to the "philopsophy" section of the README that states we do not wish to represent programs that would otherwise be syntactically valid if not for their early errors.

[bakkot]

@michaelficarra that would be a good note to add, but I observe that this is already the case: e.g. in es2015 the LHS of an AssignmentExpression must be a Pattern, but this is only required because of an early error.

[mikesherov]

@RReverser seems we need to accompany this with a note in philosophy re: early errors. Care to PR that also?

[RReverser]

@mikesherov Last time couldn't think of a good wording to specify that, I can give it another try.

[adrianheine]

Quick first draft: »ESTree is intended to be able to represent valid ECMAScript scripts and modules. It is not required to support programs that follow the ECMAScript syntactic grammar, but would produce early errors during parsing. See the introduction to the syntactic grammar in the ECMAScript spec.«

[adrianheine]

We might also want to clarify that it's obviously possible for an invalid source to be representable with ESTree.

[nzakas]

@RReverser do you want to move forward with this or should it be closed?

[RReverser]

I think it's still useful and valuable, but there was some confusion above as to whether ESTree should represent nodes that wouldn't pass early errors checks.

[nzakas]

How would you like to proceed? If you’d like to push forward, I’d suggest summarizing the discussion to this point to make it easier to pick up for others.