Repository: TypeScript
Issue: `in` keyword completions
Labels: Suggestion,Domain: Completion Lists,Awaiting More Feedback

# Suggestion

<!--
  Please fill in each section completely. Thank you!
-->

## 🔍 Search Terms

in keyword completions
in keyword suggestions
in keyword intellisense

<!--
  💡 Did you know? TypeScript has over 2,000 open suggestions!
  🔎 Please search thoroughly before logging new feature requests as most common ideas already have a proposal in progress.
  The "Common Feature Requests" section of the FAQ lists many popular requests: https://github.com/Microsoft/TypeScript/wiki/FAQ#common-feature-requests

  Replace the text below:
-->

## ✅ Viability Checklist

<!--
   Suggestions that don't meet all these criteria are very, very unlikely to be accepted.
   We always recommend reviewing the TypeScript design goals before investing time writing
   a proposal for ideas outside the scope of the project.
-->
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](https://github.com/Microsoft/TypeScript/wiki/TypeScript-Design-Goals).


## ⭐ Suggestion

<!-- A summary of what you'd like to see added or changed -->

Typescript [docs says](https://www.typescriptlang.org/docs/handbook/2/narrowing.html#the-in-operator-narrowing) 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

```ts
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](https://github.com/zardoy/typescript-vscode-plugins/pull/19), but also decided to make as much informative as possible:

![image](https://user-images.githubusercontent.com/46503702/174466763-d6c1a5b9-d150-45de-801d-3407f14ef9b1.png)

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.:

```ts
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.

<!--
  If you were announcing this feature in a blog post, what's a short explanation that shows
  a developer why this feature improves the language?
-->

## 💻 Use Cases

<!--
  What do you want to use this for?
  What shortcomings exist with current approaches?
  What workarounds are you using in the meantime?
-->