v := v is technically also shadowing, but it's also a useful idiom inside a loop. I think that's the reason vet doesn't complian about this case.

it's also a useful idiom inside a loop

please be more specific :)

what this idiom is useful for?

Making the variable local to the loop body, primarily for closures:

for _, v := range s {
  v := v
  go func() {
    fn(v)
  }()
}

That is mentioned in the last part of https://golang.org/doc/faq#closures_and_goroutines.

Making the variable local to the loop body, primarily for closures:

is it any better than

for _, v := range s {
  localV := v
  go func() {
    fn(localV)
  }
}

You can accidentally use v inside closure that way.

fair enough.

so vet should check the types I guess. same type ok, not the same type should cause a warning...

what do you think?

so vet should check the types I guess. same type ok, not the same type should cause a warning...
what do you think?

When you iterate over some interface types that represent ADT-like values (see example below), you may want to introduce type-asserted version of it inside inner scope:

	// A.
	for _, decl := range f.Decls {
		decl, ok := decl.(*ast.FuncDecl)
		if !ok {
			continue
		}
		// Use func decl.
	}

	// B: makes code more nested. Also does shadowing.
	for _, decl := range f.Decls {
		if decl, ok := decl.(*ast.FuncDecl); ok {
			// Use func decl.
		}
	}

At least for me, it feels consistent with type switch idiom where you do assignment to the variable of the same name:

switch n := n.(type) {
case A:
	// n is of type A.
case B:
	// n is of type B
}

@AlekSi how about this one?

for _, v := range s {
  v = v
  go func() {
    fn(v)
  }()
}

cmd/vet/README lists the requirements for a vet check.
This proposal seems to me to fail "Correctness" and "Precision".

There is plenty of code that shadows variables explicitly to make a local copy, and reuses the same name to ensure that it is impossible to refer to the outer "wrong" one anymore. (I'm just repeating the conversation above, with @dominikh and @onokonem).

Rejecting "obvious" shadowing like this will generate far too many false positives, which makes people not trust vet output (even output from other checks).