gopls supports textDocument/implementation for Go interfaces, but it does not currently expose implementation counts through CodeLens.
This means editors that rely on server-provided CodeLens data cannot show a common IDE affordance such as:
type Reader interface { // 3 implementations
Read([]byte) (int, error)
}This would be useful for quickly discovering interface usage and navigating large codebases without explicitly invoking "Go to Implementation" first.
A possible design is to add an optional CodeLens source for Go files, for example:
{
"codelenses": {
"implementation": true
}
}The source could annotate non-empty interface type declarations with 1 implementation / N implementations.
To avoid making textDocument/codeLens expensive, the initial request could only scan the current file for candidate interface declarations and return unresolved CodeLens items. The implementation count could then be computed lazily through codeLens/resolve, reusing the existing implementation query machinery.
For navigation, the resolved CodeLens could use the existing gopls.lsp command to issue a standard textDocument/implementation request. Clients that support handling command results may present the returned locations using their normal implementation UI; clients that do not would still benefit from the implementation count.
goplssupportstextDocument/implementationfor Go interfaces, but it does not currently expose implementation counts through CodeLens.This means editors that rely on server-provided CodeLens data cannot show a common IDE affordance such as:
This would be useful for quickly discovering interface usage and navigating large codebases without explicitly invoking "Go to Implementation" first.
A possible design is to add an optional CodeLens source for Go files, for example:
{ "codelenses": { "implementation": true } }The source could annotate non-empty interface type declarations with 1 implementation / N implementations.
To avoid making textDocument/codeLens expensive, the initial request could only scan the current file for candidate interface declarations and return unresolved CodeLens items. The implementation count could then be computed lazily through codeLens/resolve, reusing the existing implementation query machinery.
For navigation, the resolved CodeLens could use the existing gopls.lsp command to issue a standard textDocument/implementation request. Clients that support handling command results may present the returned locations using their normal implementation UI; clients that do not would still benefit from the implementation count.