Repository: TypeScript
Issue: Inlay Hints: Improve hints for complex data types and arrays in particular
Labels: Suggestion,In Discussion,Domain: Inlay Hints

# Suggestion

<!--
  Please fill in each section completely. Thank you!
-->

## 🔍 Search Terms

<!--
  💡 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:
-->

- inlay hints
- inlay hints array

Related: https://github.com/microsoft/TypeScript/issues/45295

## ✅ 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:

- not relevant, this is about tooling


## ⭐ Suggestion

<!-- A summary of what you'd like to see added or changed -->

*I've been told that this repo is the correct place to suggest such a feature (via https://github.com/typescript-language-server/typescript-language-server/issues/639).*

Sometimes Inlay hints are too long and get cut off at some point ([after 30 characters](https://github.com/microsoft/TypeScript/blob/00dc0b6674eef3fbb3abb86f9d71705b11134446/src/services/inlayHints.ts#L73-L73)) and having the array braces at the end makes them very likely to be cut off despite it being the outer-most structure, 
making it almost impossible to tell from the hint that this function returns an array (only from the leading `(`), whereas this would be easy if instead it showed `: Array<{ key: string; tdC...`.

For reference, rust-analyzer does this more elegantly by leaving out details in the inner element if a configurable threshold of characters would otherwise be exceeded while still including all relevant punctuation for the outer types:

![2022-12-13_20-33-17](https://user-images.githubusercontent.com/931051/207427772-8b21108b-9586-4dba-9c44-04ba25b80c9f.png)

For this example, that would probably become  `: Array<{ key: string; … }>` or `: ({ key: string; … })[]` (depending on a configurable threshold).

## 📃 Motivating Example

<!--
  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?
-->

The following example illustrates the current problem with not being able to tell (quickly) that the return type is an array.

```
:: --> LSP-volar textDocument/inlayHint(657): {'textDocument': {'uri': 'file:///File.vue'}, 'range': {'end': {'line': 129, 'character': 0}, 'start': {'line': 0, 'character': 0}}}
:: <<< LSP-volar 657: [{'kind': 1, 'position': {'line': 71, 'character': 23}, 'paddingLeft': True, 'label': ': ProductionSpecification[]'}, {'kind': 1, 'position': {'line': 79, 'character': 28}, 'paddingLeft': True, 'label': ': boolean'}, {'kind': 1, 'position': {'line': 82, 'character': 21}, 'paddingLeft': True, 'label': ': ({ key: string; tdClass: st...'}, {'kind': 1, 'position': {'line': 90, 'character': 63}, 'paddingLeft': True, 'label': ': Promise<void>'}, {'kind': 1, 'position': {'line': 91, 'character': 24}, 'paddingLeft': True, 'label': ': any'}]
```

![2022-12-13_20-31-14](https://user-images.githubusercontent.com/931051/207427496-bca414f2-cbec-4ba2-88ed-94b974ce7b7c.png)



## 💻 Use Cases

<!--
  What do you want to use this for?
  What shortcomings exist with current approaches?
  What workarounds are you using in the meantime?
-->

See above.