Consider this multi-file snippet:

package main

import "play.ground/foo"

func main() {
	foo.MyFunc()
}

package foo // play.ground/foo

import "play.ground/foo/internal/foo"

type Foo = foo.InternalFoo

func MyFunc(Foo) {}

package foo // play.ground/foo/internal/foo

type InternalFoo int

Compiling this project produces the following error:

# play.ground
./prog.go:6:12: not enough arguments in call to "play.ground/foo".MyFunc
	have ()
	want ("play.ground/foo/internal/foo".InternalFoo)

While technically correct, this error message is unhelpful for the end user since they are unable to access "play.ground/internal/foo".InternalFoo since it is declared in an internal package.

If possible, the compiler should report the name of a type that the user can access. While this is not possible in all cases, a reasonable heuristic is to use the name of the type in the function/method signature. In the example above, it would be "play.ground/foo".Foo.

Currently, I am refactoring a widely used package in a large code base. As part of the migration, I needed to move some types to an internal package. Since the compiler error messages point to the internal declarations, I keep getting repeated requests from users to "externalize" these types. Users do not realize that they are actually already externalized, but through an alias elsewhere. I've already documented on the internal type where to find the external version, but that has not stopped the requests.