A few weeks ago, I listened to the GoTimeFM interview https://twitter.com/GoTimeFM/status/1255875570275094529 with @eliasnaur, and thanks to interviewers and organizers @mdlayher @joncalhoun @jboursiquot @johanbrandhorst @rakyll

Motivations

In that episode, one of the things that they mentioned that they liked and mentioned about Go being a modern language is that the Go compiler is prescriptive in its error messages; for example lwhen you try to use a field with mismatched case, we'll error with the suggestion of the mismatch e.g.
Given this program https://play.golang.org/p/CRyflGpyRyg or inlined below:

package main

type A struct {
	b int
}

func (a *A) S() {}

func main() {
	var a A
	_ = a.B
	a.s()
}

which produces

./prog.go:11:7: a.B undefined (type A has no field or method B, but does have b)
./prog.go:12:3: a.s undefined (type A has no field or method s, but does have S)

Suggestion

The error messages are nice but I think that we can be even more prescriptive and say

./prog.go:11:7: a.B undefined (type A has no field or method B, but does have field b)
./prog.go:12:3: a.s undefined (type A has no field or method s, but does have method S)

I just submitted another CL 201657 to fix #31053, in which we improve the error for unexported fields by telling the user for example

./main.go:3:21: cannot refer to unexported field 'doneChan' in struct literal of type http.Server
./main.go:5:12: srv.newConn undefined (cannot refer to unexported method http.(*Server).newConn)
./main.go:6:12: srv.doneChan undefined (cannot refer to unexported field doneChan)

while in that CL, at some point I implemented some logic for defining the distinction between field and method but it was deemed to be beyond the scope of issue #31053 per comment/typecheck.go#925

so this issue is a placeholder for that functionality. I can have a CL ready in about 10 minutes, and we also have the motivation which is the reception and feedback that Go users provide us.

The end result is that instead of

./prog.go:11:7: a.B undefined (type A has no field or method B, but does have b)
./prog.go:12:3: a.s undefined (type A has no field or method s, but does have S)

we'll now have

./prog.go:11:7: a.B undefined (type A has no field or method B, but does have field b)
./prog.go:12:3: a.s undefined (type A has no field or method s, but does have method S)

Kindly paging my fellow compiler+syntax crew @mdempsky and @griesemer who have been helping with reviews for these updates for us to further improve compiler error messages.