Is MemberExpression a Pattern?

[cpcallen]

es5.md says:

Nevertheless, for ES5, the only Pattern subtype is Identifier.

But this is not true; MemberExpression is defined thusly:

interface MemberExpression <: Expression, Pattern {
    type: "MemberExpression";
    object: Expression;
    property: Expression;
    computed: boolean;
}

This is great, because ForInStatement is defined thusly:

interface ForInStatement <: Statement {
    type: "ForInStatement";
    left: VariableDeclaration |  Pattern;
    right: Expression;
    body: Statement;
}

…and indeed we can use a MemberExpression in a ForInStatement, and it works exactly as you would expect:

var o = {foo: bar}
var a = {a:1, b:2, c:3}
for(o.foo in a) { alert(o.foo) }

However, es5.md also declares Function.params as [Pattern] and CatchClause.param as Pattern, and ECMA262 5.1 clearly restricts these to [Identifier] and Identifier respectively, so perhaps it is the definitions of MemberExpression and ForInStatement which are wrong?

(Actually, ForInStatement is definitely wrong; per @michaelficarra's reasoning in #160, ForInStatement.Left can actually be any Expression (see https://www.ecma-international.org/ecma-262/5.1/#sec-12.6.4, where it is a LeftHandSideExpression which in turn can be any expression), which means that the following bizarre construction is (syntactically) legal:

for(f() in myObject) { /* ... */ }

…and for consistency should be representable as an estree.)

I am not sure which of these solutions is preferable, either in general or specifically in terms of impact on the the estree es201[567].md specs; unfortunately I have not managed to get my head around the full ECMA262 7.0 spec sufficiently to understand what precisely is now allowed in function and catch clause parameter declarations.

[RReverser]

Sounds like duplicate of #161

[cpcallen]

@RReverser: you are basically correct; I had not seen that issue. Apologies for opening a near-duplicate.

I do think it would be helpful if the description of Pattern was consistent with the actual definition, however, so I will leave this issue open so that that at least might be addressed—perhaps by someone with a better understanding of the legacy, interoperability and post-5.1 issues than me.

(One criteria for a good enough description of Pattern might be "prevents further well-meaning but ill-informed duplicates of #161"...)

[RReverser]

I agree, it's just that neither of proposed PRs currently fixes it correctly - in both cases, you end up with either breaking correct representation or duplicating same lists of actual node types in every field.

While ESTree spec itself is really more of representation spec rather than precise type system (this is best left to ESTree's TypeScript definitions which describe relations between different types more correctly), this is something we could fix in this specific case by creating a descendant of Pattern called e.g. DeclarationPattern and using it in these very few contexts where only declaration patterns are allowed and not any assignable ones (variable declaration, function param list and such).