Part of #63352

The current mechanism takes the last segment of the package path and appends a numeric suffix (if needed) to ensure uniqueness. This produces low-quality local names such path2, format3 and strings5.

I propose to add strategies (2), (3) and (4), as illustrated below, to generate better names. These follow common practices for package aliasing and result in more meaningful names.

  1. Try PkgName (unchanged).
  2. Try the local alias of the callee. (There is a todo comment in inline.go#525)
  3. Try PkgName + "pkg". For example, path becomes pathpkg.
  4. Prepend the preceding path segment if available. For example, golang.org/x/tools/internal/astutil becomes internalastutil.
  5. Appending a numeric suffix (unchanged). For example, path becomes path1, path2, ...

I'd love to implement these myself.

Alias examples in OSS repositories:

  1. Strategy 3 a. path as pathpkg: 14 usages in golang/tools, 11 usages in golang/go b. urlpkg, tracepkg, errorspkg, stringspkg, logpkg, htmlpkg, etc. in golang/go and golang/tools c. nodepkg, volumepkg, auditpkg, controllerpkg, etc. in kubernetes/kubernetes
  2. Strategy 4 a. internalastutil: 11 usages in golang/tools b. metav1: 2700+ usages in kubernetes/kubernetes c. apierrors: 564 usages in kubernetes/kubernetes d. utilerrors: 165 usages in kubernetes/kubernetes

Comment From: gavinkflam

@adonovan What are your thoughts?

I'd love to implement the new strategies and submit a PR.

Comment From: thediveo

I find the examples you give very hard to read, more so within code. It would work though in several cases I've come across with protobuf-originating packages that are versioned, such as Docker, OTel, ... Not sure if CamelCasing would improve the situation. Also, my example with protobuf packages wouldn't necessarily be handled here and I see too few import clashes to really want help here, especially when there's some chance of getting "internal" as part of it into the game. The repo name might be much more descriptive, but then, what's a repo name and where is it in an arbitrary import path?

Comment From: gavinkflam

Camel case is a good idea. Perhaps strategy 3 can benefit from a limit of two or three segments too. Given that clashes don't happen too often, that should cover most of the cases.

Repo name prefix - I have seen that being used but it's hard to automate as you mentioned.

Internal - do you mean internalPath, internalFmt, etc.?

Comment From: thediveo

You might meet some resistance on proposing CamelCase on import identifiers; maybe you want to discuss your ideas first in the golang-nuts group and gather hopefully valuable feedback?

Comment From: gavinkflam

Thank you. I'd love to discuss this in golang-nuts and get some feedbacks from @adonovan.

I’ve added a strategy to reuse the callee alias and refined the strategy of prepending preceding path segments. I’ve also included usage examples from open-source repositories for reference.

Moreover, I did some research on CamelCase. It is not idiomatic likely due to case-insensitive file systems on Windows and macOS. Underscores are also not idiomatic according to https://go.dev/blog/package-names.