Property autocompletion includes Symbol when object has a well-known symbol as key

[uhyo]

Bug Report

🔎 Search Terms

property autocompletion symbol well-known

🕗 Version & Regression Information

TypeScript 4.9.4

• This is the behavior in every version I tried, and I reviewed the FAQ for entries about ?

⏯ Playground Link

Playground link with relevant code

Sorry but please note that I wasn't able to reproduce the issue on the playground. The issue was reproducible on my VSCode 1.74.3, with extensions disabled, and TypeScript 4.9.4.

💻 Code

const obj = {
  field: 0,
  [Symbol.asyncIterator]() {}
};

obj.
//  ^autocompletion here

tsconfig.json:

{
  "compilerOptions": {
    "target": "esnext",
    "strict": true
  },
  "include": ["index.ts"]
}

🙁 Actual behavior

Symbol is shown as a autocompletion candidate.

Selecting it produces obj[Symbol] which isn't correct.

🙂 Expected behavior

Should offer Symbol.asyncIterator.

[Andarist]

The reason why it's not reproducible in the TS playground is that this depends on includeCompletionsWithInsertText: true user preference.

[Andarist]

So it seems that adding Symbol is currently intentional (introduced in #23091 ):

TypeScript/src/services/completions.ts

Lines 3523 to 3525 in 6f7704e

	// For a computed property with an accessible name like `Symbol.iterator`,
	// we'll add a completion for the *name* `Symbol` instead of for the property.
	// If this is e.g. [Symbol.iterator], add a completion for `Symbol`.

and this completion entry might be rejected conditionally based on includeCompletionsWithInsertText here:

TypeScript/src/services/completions.ts

Lines 1742 to 1744 in 6f7704e

	if (insertText !== undefined && !preferences.includeCompletionsWithInsertText) {
	return undefined;
	}

I find the intention here somewhat questionable, especially since the cursor is put after the closing bracket (obj[Symbol]/**/). So you can't even immediately chain from Symbol after choosing that.

I think that at the very least the cursor's position should be different after chosing that completion but I agree with OP that it would be even better to suggest concrete symbols there (like Symbol.iterator, Symbol.asyncIterator, etc). Perhaps it's already implemented like that but I feel like those definitely should have the lowest possible priority~ assigned to them. Most people don't care about those so those should appear at the bottom of the list.

It would also be cool if the list could be filterable by the concrete name of the symbol.