Enable interfaces to provide sample implementations of functions for IDEs to inject

[sjpotter]

What version of Go are you using (go version)?

$ go version
go version go1.13.3 linux/amd64

Does this issue reproduce with the latest release?

not a bug, but a commenting feature request

What operating system and processor architecture are you using (go env)?

go env Output

$ go env
GO111MODULE=""
GOARCH="amd64"
GOBIN=""
GOCACHE="/home/spotter/.cache/go-build"
GOENV="/home/spotter/.config/go/env"
GOEXE=""
GOFLAGS=""
GOHOSTARCH="amd64"
GOHOSTOS="linux"
GONOPROXY=""
GONOSUMDB=""
GOOS="linux"
GOPATH="/home/spotter/go"
GOPRIVATE=""
GOPROXY="https://proxy.golang.org,direct"
GOROOT="/usr/local/go"
GOSUMDB="sum.golang.org"
GOTMPDIR=""
GOTOOLDIR="/usr/local/go/pkg/tool/linux_amd64"
GCCGO="gccgo"
AR="ar"
CC="gcc"
CXX="g++"
CGO_ENABLED="1"
GOMOD=""
CGO_CFLAGS="-g -O2"
CGO_CPPFLAGS=""
CGO_CXXFLAGS="-g -O2"
CGO_FFLAGS="-g -O2"
CGO_LDFLAGS="-g -O2"
PKG_CONFIG="pkg-config"
GOGCCFLAGS="-fPIC -m64 -pthread -fmessage-length=0 -fdebug-prefix-map=/tmp/go-build007852437=/tmp/go-build -gno-record-gcc-switches"

What did you do?

using an inteface and had IDE implement missing interface functions

What did you expect to see?

usable functions that don't just panic

What did you see instead?

functions that panic

as an example. if I pass a structure that is supposed to implement the http.Handler interface and I haven't implemented ServeHTTP() on it, the IDE (say goland) will complain and ask me if I want to implement the missing functions. it does this by creating a function that just panics.

i.e.

func (h Handler) ServeHTTP(w http.ResponseWriter, r *http.Request) {
        panic("implement me")
}

I'm wondering if it wouldn't be better to be able to annotate interfaces to provide more valuable "Implement Me" implementations, which could then be used by IDEs

func (h Handler) ServeHTTP(w http.ResponseWriter, r *http.Request) {
	w.WriteHeader(501)
	_, _ = w.Write([]byte("Implement Me"))
}

of course its possible that people prefer implement me's that panic. one would also have to figure out how to deal with multiple templates provided by different interfaces that require the same function. (unsure so difficult, not so different than what happens when multiple imports seem to match and the IDE asks which one you want)

[hantmac]

In my opinion, Go's philosophy is preferrinng panic than implement me

[sjpotter]

that's my question, is this really Go's philosophy? that there would be negative value to providing a template function that doesn't just panic?

if it is, so be it, I just haven't seen anything that says that. And note, this wouldn't require every interface method to be annotated as such, just that if it is, can provide the IDE something possibly more useful to the end user developer.

[martisch]

From the report its unclear to me what the actionable change is here in context of Go itself? Is there a specific change in the language needed, how does it look like?
Please use https://go.googlesource.com/proposal/+/refs/heads/master/go2-language-changes.md for more details to evaluate the proposal.

Or is this about a feature request in gopls or a specifc IDE?

[sjpotter]

its not a language change, as I'd imagine it just be a comment on the interface, that's why I'm not sure its really a go2 issue.

i.e. the actionable thing is either "there's a value in providing an interface implementation sample for IDEs to include and hence creating a standard or there isn't and hence this should be closed.

but it might be more relevant to gopls, I'm not sure.

[martisch]

I have not seen the Go Language Specification giving any semantics to the content of comments for editors.

If this issue is for gathering opinions in the abstract I think its better discussed on the mailing lists or other forums first to then propose a concrete language change or comment standard that can be evaluated as a proposal. Alternative (as it is up to the tools outside the go compiler to interpret comment examples) is to make a feature request to the IDE of choice directly.

[sjpotter]

ok. makes sense.

[stamblerre]

Closing this, as Goland is not published by the Go team. I am sure there is a way to report issues to Goland from inside the IDE.

However, I agree with @hantmac that the panic is preferable. We cannot guess what code the user wants to write, and if they forget to implement the function a panic is the easiest thing to debug.

The Go team does support gopls, however, and we do have a feature request open for this: #37537.