@matloob PTAL.

IIUC this is the expected behavior. From the code:

	// Don't complain if the types differ: that implies the programmer really wants two different things.

From the documentation "A shadowed variable is a variable declared in an inner scope
with the same name and type as a variable in an outer scope," [emphasis added].

In the example, y is not identical to x as they are different named types.

I am missing the history for why shadow looks for the types to be identical and not the Underlying type to be identical. I am guessing there was a good reason though.

As I recall it's simply that if the shadowing (inner) variable x is a different type, then almost any use of the shadowing x that intended to use the shadowed (outer) x would get an error anyhow. (I suppose that slice indexing is an exception to that, though.)

@ianlancetaylor I think my question is essentially, why is the test on the type (current Analyzer code):

	if types.Identical(obj.Type(), shadowed.Type()) {

instead of the underlying type:

	if types.Identical(obj.Type().Underlying(), shadowed.Type().Underlying()) {

Both seem somewhat reasonable for a shadow checker to me. For very different types, a type checking error does seem quite likely.

Here is a modified version of the original example that gives me some pause for whether switching from type identity to Underlying type identity makes sense. Here we have x and y with the same underlying type but different methods.

package main

import "fmt"

type x int
func (v x) Foo() {	fmt.Println("x.Foo()", v)}

type y x
func (v y) Foo() {	fmt.Println("y.Foo()", v)}

func main() {
	as := []int{1, 2, 3}
	bs := []int{10, 20, 30}
	for _, a := range as {
		v := x(a)
		for _, b := range bs {
			v := y(b)
			v.Foo()
		}
		v.Foo()
	}
}

https://play.golang.org/p/OtMybbfQ6nT

I see. I think I did misunderstand this. I have no answer for your question. It's probably fine to change it.