Ian's been making changes to that heuristic under the assumption that it only affects goimports, where the worst case is that some user code churns. Dunno how safe it is to export it.

@ianthehat

Perhaps we can export it once the heuristic has stabilized?

I think the original issue isn't about astutil.UsesImport primarily, but since it is mentioned, I want to provide the following information about it.

I have a local WIP commit that mentions astutil.UsesImport. I discovered a fundamental issue with it. Fixing the issue may only be possible by breaking the API. As a result, it may make more sense to deprecate the current UsesImport. I wasn't sure if many people use it, and whether it'd be worthwhile to deal with it, so the WIP commit left sitting behind.

I'll copy the commit message here, since it's relevant:

commit 16fa2d7c70732cd3ee2b4e007b4cda9e4ed52e6a
Author: Dmitri Shuralyov <dmitshur@golang.org>
Date:   Thu Nov 1 00:37:20 2018 -0400

    WIP: go/ast/astutil: try to fix UsesImport
    
    UsesImport is broken in that it will return true or false
    on the same input if you just reorder the imports.
    
    UsesImport is hard to fix properly without breaking its API.
    To make some sort of sense, it'd need to accept both import name
    and path. Not just path.
    
    So, before doing anything about it, see if it's even worth it.
    Maybe the best way forward is to deprecate it or remove it.
    
    Change-Id: If878f625fec48ae36d510a93b11285e0c6003fd6

 go/ast/astutil/imports.go      | 61 +++++++++++++++++++++++-------------------
 go/ast/astutil/imports_test.go | 12 +++++++++
 2 files changed, 46 insertions(+), 27 deletions(-)

The heuristic was deliberately extracted to the function importPathToAssumedName so that it could possibly be exposed one day.
Probably needs some more discussion about whether the heuristic is reasonable and complete.