Consider reducing requirements for results provided by extensions

[alexdima]

notice how the return type is now: ProviderResult<data<T[] | CompletionList<T>>>

export type data<T> = T extends Function
	? never
	: T extends object // recurse
	? { [k in keyof T]: data<T[k]>; }
	: T;

export interface CompletionItemProvider<T extends CompletionItem = CompletionItem> {
	//...
	provideCompletionItems(document: TextDocument, position: Position, token: CancellationToken, context: CompletionContext): ProviderResult<data<T[] | CompletionList<T>>>;
	//...
}

this would allow an extension to use the following (and not need to allocate a real range using new vscode.Range):

provideCompletionItems(/*...*/) {
	return [{
		label: 'hello',
		range: {
			start: { line: 10, character: 0 },
			end: { line: 10, character: 1}
		}
	}];
}

[dbaeumer]

Although not an enforcement I would declare the return type as follows:

ProviderResult<T[] | data<T>[] | CompletionList<T> | CompletionList<data<T>>>>

And would spec that the list should be homogenous. E.g. we assume if the first element is a CompletionItem all items are instances of CompletionItem

[jrieken]

I generally like but I am unsure that's the full thing. To a certain extend you can already do that today with provider results that have "function-less" data, e.g code lenses or completions without ranges. However, we will still iterate over these objects and we still convert them into DTO types - so from lsp-dto into our dtos and on the renderer into domain objects. I am also unsure if our "function-less" types correspond to lsp-dtos or if they first need to be transformed... So, let's measure how much this can actually save.

An alternative is to find a way such that LSP object can be passed through. Like, vscode.Range#toJSON could be spec'd to return the LSP range. We then have a special class implementing vscode.Range by wrapping around a JSON blob which it only accesses/unwraps lazily and usually simply forwards in its toJSON implementation

[dbaeumer]

First measuring makes perfect sense. What I will do is the following:

• write code that in place modifies a LSP JSON result to a data including range and position.
• run test for completion items and diagnostics since I think these are the once we convert the most.