Skip to content

in inside an array literal in a for initializer is a syntax error (for (let i = 0, a = [k in o]; …))Β #65311

Open

Description

@trackoor

πŸ”Ž Search Terms

in operator for loop initializer array literal, TS1005 ',' expected, DisallowInContext, for head in expression, for-of destructuring default in

πŸ•— Version & Regression Information

This is the behavior in every version I tried: 5.9.3, 6.0.3, 7.0.2, 7.1.0-dev.20261103.1 (typescript@next) and main e2bc2bc. Not a regression.

⏯ Playground Link

No response

πŸ’» Code

const o = { a: 1 }, k = "a";
for (let i = 0, has = [k in o]; i < 1; i++) {}
for (let i = 0, has = { v: k in o }; i < 1; i++) {}
for (let i = 0, has = (k in o); i < 1; i++) {}
let x;
for ([x = "x" in {}] of [[]]) {}

πŸ™ Actual behavior

tsc --noEmit --target esnext --module esnext --pretty false t.ts:

t.ts(2,26): error TS1005: ',' expected.
t.ts(2,30): error TS1005: ')' expected.
t.ts(2,43): error TS1005: ';' expected.
t.ts(6,15): error TS1005: ',' expected.

Lines 2 and 6 fail. The same k in o inside an object literal (line 3) or parentheses (line 4) is accepted, as it is in call arguments and template substitutions.

πŸ™‚ Expected behavior

No errors. The [~In] of the for head (for ( LexicalDeclaration[~In] Expression[+In]opt ; …), for ( Expression[~In]opt ; …), https://tc39.es/ecma262/#sec-for-statement) does not reach into array literals: ElementList : AssignmentExpression[+In] (https://tc39.es/ecma262/#sec-array-initializer), the same as for object literal property values. In the for-of case the array literal is an ArrayAssignmentPattern, whose Initializer[+In] also allows in. node accepts the file; for (let i = 0, has = [k in o]; i < 1; i++) console.log(has); prints [ true ].

Additional information about the issue

parseArrayLiteralExpression in internal/parser/parser.go parses its elements in the caller's context, so NodeFlagsDisallowInContext from the for initializer is still set. parseArgumentExpression already clears it for call arguments. Clearing it for the element list fixes both lines:

elements := p.doInContext(ast.NodeFlagsDisallowInContext, false, func(p *Parser) *ast.NodeList {
	return p.parseDelimitedList(PCArrayLiteralMembers, (*Parser).parseArgumentOrArrayLiteralElement)
})

With that change on main, the code above has no errors, for (var q = "a" in o; ;) break; is still rejected, and go test ./internal/parser/ passes.

Activity

  1. MartinJohns commented on Nov 4, 2026

    @MartinJohns
    Contributor

    Why would you ever write code like this?

  2. trackoor commented on Nov 4, 2026

    @trackoor
    Author
    1. Why would you ever write code like this?

    I found this while checking the parser against our own parser impl & test262. It is an uncommon pattern tho.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    BugA bug in TypeScript

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions