Please show complete code.

Is that a new err variable or an existing err? Maybe only body is new in that snippet. If so, that's a different feature request.

Hello @bradfitz thanks for the quick reply. The second to the last line of the function has err redeclared. Was expecting that running go vet will flag it when there are no usage of err var after it got redeclared.

The err variable isn't redeclared there. Only body is declared. The err variable is just reassigned.

That is, your bug report or feature request is equivalent to:

package vettest

func foo() {
        a := 1
        if a == 2 {
                // ...
        }
        a = 3 // no vet warning here                                                                                                                                              
}               

FTR, staticcheck as well as ineffassign catch this.

Moved this into the proposal process to replace #40286.
The proposal here is to have cmd/vet do more precise "assigned and not used" checks than the compiler does.
For example the compiler rejects:

 x := 1
 ... no use of x ...

but it does not flag the first assignment in:

x := 1
x = 2
... use of x ...

nor the second in:

x := 1
... use of x ...
x = 2

Vet could flag both of those cases (for all types of variables, not just errors).

What's needed here is a simple implementation and then some info about whether there are false positives or just too many reports on existing Go code.

@spf13 points out that some people like to write

x := T{}

instead of

var x T

and that we probably should not flag lack-of-use for a := declaration+assignment that is assigning a zero value.

I initialize a slice index to -1, so that if it's used without being reassigned, slice[index] gives a runtime error.

int x := -1
for x = 0; x < len(s) && s[x] != y ; x++ { }
f(&s[x])

Does anyone want to try writing this check and see how many false positives it has?

In theory this seems like a good idea, but there are many possible implementations with subtle differences.
Placing this issue on hold until we have more concrete details about a specific vet check to evaluate.

There are already two different implementations: staticcheck and ineffassign. In my experience, they have almost no false positives, or no worse than anything reported by go vet. And given that many devs already run staticcheck across their codebase, those ones are likely to be "assigned-but-not-used" clean, so I don't think this will be a huge burden to the community.