Parse error on private identifier optional chain

[joeywatts]

Previously, this error was reported in the checker, so JS files with checkJs: false were not erroring on this invalid syntax.

Addresses the optional chaining part of #35962.

[DanielRosenwasser]

I think it would be better to just put the privatename identifier on the node so that the language service still works

[DanielRosenwasser]

Should this be a grammar error in the binder @sandersn?

[joeywatts]

I was looking around and it seems like diagnostics from the binder and checker are discarded for JS files that have checkJs off.

TypeScript/src/compiler/program.ts

Lines 1736 to 1737 in 18269c0

	const includeBindAndCheckDiagnostics = !isTsNoCheck && (sourceFile.scriptKind === ScriptKind.TS || sourceFile.scriptKind === ScriptKind.TSX ||
	sourceFile.scriptKind === ScriptKind.External || isCheckJs || sourceFile.scriptKind === ScriptKind.Deferred);

[ajafff]

@joeywatts where is this restriction documented? I searched in the proposal specs and didn't find anything useful.
I tried optional chaining with private properties in Node.js 13.5 and it worked without error (something like a?.b?.#c?.d). So either this is a bug in V8 or this restriction doesn't really exist.

[joeywatts]

See the syntax for Optional Chaining in the ES2020 Specification. It only supports IdentifierName, [ Expression ], Arguments, or TemplateLiteral after ?. (so no PrivateIdentifier). The spec text for the class fields proposal does not modify optional chaining to support private identifiers.

[DanielRosenwasser]

I think that the only reason that it's not allowed is because the two proposals developed separately. I would be happy to bring forward a proposal to remove the restriction (because why not I guess?) unless @littledan wants to add PrivateIdentifier to OptionalChain for the class fields proposal.

[littledan]

@DanielRosenwasser I didn't communicate or justify it well, but disallowing the combination was intentional on my part. However, now TC39 has revisited this and decided that the combination should be allowed, see tc39/proposal-class-fields#301. So, this change should be revisited (reverted?).