Hello @stamblerre and @ridersofrohan, is expanderr functionality still being considered for gopls? It seem like it had been close based on the initial CL from @stapelberg that @stamblerre then took over:

https://go-review.googlesource.com/c/tools/+/188637

I think goreturns might be more well-known, but at least in my personal opinion I think expanderr might be better (with “better” of course being subjective).

From the expanderr README:

How does expanderr differ from goreturns?

goreturns only inserts a return statement with zero values for the current function.

expanderr understands the signature of the call expression under your cursor and inserts the appropriate error checking statement (including a return statement). In practice, this eliminates the need of combining goreturns with an editor snippet, with the additional bonus of working correctly in a larger number of situations.

The reasoning behind goreturns is because VS Code Go supports it as a formatter option, and we wanted to make sure that we had feature parity with that first. I don't have the time to continue with the expanderr work, but I could certainly see that as being a follow-up to this issue.

Change https://golang.org/cl/224960 mentions this issue: internal/lsp: add goreturns like functionality as quickfix