But here's a gotcha:

        switch r {
        case 64, 64:
        }

Should we warn about 64 or about '@' here? I guess it depends on what the user used in the source code, as 64 would be better in this case. Does the compiler have access to this kind of AST info?

AFK but look in swt.go for the error message (there may be multiple of them) and look at what format verb is used to print it. It should just be a matter of picking the right verb.

Thanks - I'll look into this tomorrow.

CL https://golang.org/cl/41852 mentions this issue.

@josharian thanks for the pointer. I've come up with a small CL that seems to do the trick - input welcome.

I'd lean towards always printing the original source expression, and then maybe parenthetically including the integer value when the expression was not originally an integer literal. Something like:

/f.go:5:2: duplicate case '@' (value 64) in switch

That's similar to what go/types does:

/tmp/foo.go:8:11: duplicate case '@' (constant 64 of type int) in expression switch

Incidentally, I notice that cmd/compile and go/types produce different error messages for:

var x [1]int
var _ = x['@']

cmd/compile:

/tmp/foo.go:4:10: invalid array index '@' (out of bounds for 1-element array)

go/types:

/tmp/foo.go:4:11: index '@' (constant 64 of type int) is out of bounds

/cc @griesemer @bradfitz for input on the error messaging.

I'd lean towards always printing the original source expression, and then maybe parenthetically including the integer value when the expression was not originally an integer literal.

After Josh's input, I also lean towards that: https://go-review.googlesource.com/c/41852/1/src/cmd/compile/internal/gc/swt.go#628

I'll update the CL tomorrow.