`in` keyword completions

[zardoy]

Suggestion

🔍 Search Terms

in keyword completions
in keyword suggestions
in keyword intellisense

✅ Viability Checklist

My suggestion meets these guidelines:

• [z] This wouldn't be a breaking change in existing TypeScript/JavaScript code
• [z] This wouldn't change the runtime behavior of existing JavaScript code
• [z] This could be implemented without emitting different JS based on the types of the expressions
• [z] This isn't a runtime feature (e.g. library functionality, non-ECMAScript syntax with JavaScript output, new syntax sugar for JS, etc.)
• [z] This feature would agree with the rest of TypeScript's Design Goals.

⭐ Suggestion

Typescript docs says that in operator is usually used for object type narrowing, but sometimes you can forget property name that you want to get after narrowing. Having additional intellisense in these locations can be helpful.

TLDR Problem: having no clue what to complete in the left side of in keyword.

📃 Motivating Example

declare const foo: { a: boolean, b: string } | { a: number, c: number }

if ('' in foo) {}

This is super easy implement and I implemented it in my plugin, but also decided to make as much informative as possible:

Numbers on right side of the completions means type index, starting from actual position in the union (starting from 1).
When specific key is selected, completion widget displays the type of key in each type of the union. Star means that this key can narrow type (not present in all types of union).

I understand that sometimes these numbers can be confusing e.g.:

type Fish = /*1*/{ swim: () => void };
type Bird = /*2*/{ fly: () => void } | /*3*/{ swim: () => void };
type Human = /*4*/{ swim?: () => void; fly?: () => void };
 
function move(animal: Fish | Bird | Human) {
  if ("" in animal) {
    animal;
  } else {
    animal;
  }
}

I wonder is this even good idea to display such information, while it is super useful for me, probably it can confuse other users. However I think its worth to display documentation for each completion at least, but probably in other format. eg for swim completion from example above:

From Fish: () => void

From Bird[2]: () => void

From Human: (() => void) | undefined

Anyway its just a proposal, so let me know what you think.

And finally I think new kind of completions should be added like ts.ScriptElementKind.stringNotStrict to show client that it actually accepts arbitrary string.

💻 Use Cases

[fatcerberus]

I'm not sure how you're determining the index numbers for union members but it's very likely they are not stable; union order is an internal implementation detail and in a large enough codebase is effectively random (it depends on the order the types are first encountered while compiling, not the order they occur in the type annotation). Try reordering the union Fish | Bird | Human in your example above--without reordering the original definitions of those types--and see what happens.

[fatcerberus]

type Human = { swim?: () => void; fly?: () => void };

P.S. I kind of want to know where you're finding humans that can fly. Putting them on a plane doesn't count 😉

[talks2much]

type Human = { swim?: () => void; fly?: () => void };

P.S. I kind of want to know where you're finding humans that can fly. Putting them on a plane doesn't count 😉

It seems he took example from TS Narrowing docs, but he made a bird either fly or swim, which is funniest thing I've seen over issues so far 😆

Also having just names completions with stars is super useful, never understood what these random numbers actually mean 🤣