Description
Beyond adding support for inclusive start and exclusive end offsets to spec, commit 3854f1c added additional constraints to ParameterInformation.label
when in string form, which can preclude neat functionality for users:
Note: A label of type string must be a substring of its containing signature label.
For example, before, compliant client and servers could take advantage of not having such limitation to provide terser prototype form on SignatureInformation.label
, while providing full parameter types on each ParameterInformation.label
. Types can be rather long, so having full form just for active parameter that clients can pick from parameters
, while having short form of the rest (from SignatureInformation.label
), can provide ideal UX and better language support (see Go example bellow).
Beyond that, the current addition require clients to inform the capability of reading labels as offsets (otherwise it could potentially break clients), while the following doesn't need it.
Proposal
To solve this, while still have the added constraints available, I think the best protocol would not change ParameterInformation.label
from string
to string | [number, number]
(making a label
work as label or as highlighting), but instead add a specific field to convey a highlight over SignatureInformation.label
:
label: string, // unconstrained label
highlight?: [number, number], // "highlight" over SignatureInformation.label
This keep intentions for fields (ParameterInformation
) and sub-fields (label
) clear, while nor the previous or the current state is clear at all. And also gives room for the potential use-cases referred in this thread, which could in fact be in use already.
In this proposal label
just means to be a textual label, as it could have always been interpreted before. It is not to mean label whose job is highlighting, but when in string form (which is the usual form of labels) is unable to do that job correctly (1. there could be multiple matches, int
matches in 3 places in the int foo(int, int)
signature; 2. it's misnamed "label").
highlight
is a proper highlight (correctly named), and not an option to string
, so that it can do its job correctly as a properly indexed [number, number]
sub-string view, and never fail at that (no multiple matches).
This is nice because beyond adding an always correct highlighting, the text for label
is free from being identical to the highlight, to keep doing its job as a simple label on its own. It can't also break clients. There's no need to announce capability.
Better language support
For example, with this proposal we could have for Go a foo(a, b: int) -> int
signature label, with non matching a: int
and b: int
parameter labels (or simply int
for each), with highlight on a
or b
in the signature. It's impossible to do that with the current state.