cmd/go: overview what type implements what interface in your program

[gertcuykens]

It's frustrating for me when reading code you end up at a definition of a interface type used by a argument of a function but no idea which actual type in your program could have been passed that implemented that interface. Don't know if analysers are powerful enough to generate a overview of which type implements what interface in your program.

Is it possible to create a go vet or go doc analyser please that can generate this overview so I don't have to guess anymore or read tons of code to verify each type, thanks.

[triztian]

I think one way to mark your code as implementing an interface is by doing the following:

import "fmt"

var _ fmt.GoStringer = (*S)(nil)

// S is a custom type.
type S struct {}

// GoString implements `fmt.GoStringer`.
func (s *S) GoString() string { return "" }

You can then use the find usages of your IDE to lookup usage of a that interface in your source, say that you have the following method, you'd be able to lookup the usage of fmt.GoStringer:

func Stringy(gs fmt.GoStringer) {
  // ... code goes here ...
}

You could also make such interface assertion statements just part of your test code that way it does not get compiled for the "release" version of your project.

• Source: https://dave.cheney.net/2017/06/11/go-without-package-scoped-variables

[gertcuykens]

That's already a huge help thanks, still in addition a go vet type interface overview wouldn't hurt :P

[tmthrgd]

I've never used it, but this was mentioned in an issue (#33270) the other day: https://golang.org/lib/godoc/analysis/help.html. It looks like it's exactly what you're looking for.

[gertcuykens]

Your right the implements relation is exactly what I am looking for but maybe if that could be introduced in go doc also so you can do does analysis on just the package you are working on that would be perfect .

[bcmills]

This sort of deep analysis is not really suited to cmd/go. It's a much better fit for the gopls tool.

[bcmills]

Duplicate of #32973