Do you have a real world usecase for this? Cos honestly I'm pretty okay with this failing given its pretty nonsensical code... "just use let/const/var" is a valid workaround.

Do you have a real world usecase for this? Cos honestly I'm pretty okay with this failing given its pretty nonsensical code...

I don't expect there are real world case, this feature just begins to ship very recently.

Given that tsc already accept using D in ambient context, I don't think TSESLint should reject valid TS on the parser level. And using declaration in an ambient context is not nonsensical: compared with const C, using D tells the type compiler that D must be a Disposable or nullish value: way more narrowed than const C.

Of course if tsc decides to forbid using in ambient context, then we can close this issue, but I don't think this is a decision that we should made.

The complication is that the parser has no way to reliably detect ambient contexts without reproducing a lot of detection logic, so traditionally to allow ambient declaration syntax we must allow them wholesale in the parser, for example uninitialized const. This obviously lets a lot of invalid AST slip through, which TS OTOH can detect due to semantic analysis, so we'd rather err on the stricter side if possible.

Yeah I'm personally okay with us being incorrect here because having to detect the "ambient declaration context" is a pain and not something we do in the parser right now. Without a real-world usecase I don't personally see the motivation to build that logic in -- I don't think that academic correctness is a good enough reason.

cc @typescript-eslint/triage-team thoughts?