It seems fairly difficult to make that work with third party modules that you didn't write. The go fix would have to be perfect, which is quite difficult except in the very simplest of cases.

See also the "Automatic API Updates" section of the initial vgo blog series, as well as #32816.

@ianlancetaylor The fix doesn't have to be perfect.

In the case of a changed function signature:

Find all affected references to that function.

The maintainer provides fixes for specific usages of this function e.g. in a ast.CallExpr.

Warn about all other uses which couldn't be fixed automatically, and describe what exactly needs to be changed.

Edit: Also module/v1 and module/v2 can coexist in the same package so maybe go/fix can convert all uses which still need the old API to oldmodule.Func then import the different versions like this:

import (
     oldmodule "module/v1"
     "module/v2"
)

(I don't propose prefixing the old version with "old", just for illustration.)

@lu4p I understand that the maintainer provides the fix. If it doesn't have to be perfect, then I'm not sure why it needs any particular support from the Go toolchain. The maintainer can just say: this is what you have to change, and here is a program that can do most of the changes for you. That program can be a go fix module.

What do you think should change in the Go toolchain?

@ianlancetaylor You are right it would probably only make sense to provide "perfect" fixes.

Maybe we can have some code generation tool which can outline all the possible cases so no case is missed. Another approach would be to force the implementation of a FuncFixer interface.

Something like go fix new func

Which would generate a file like %time_func.fix.go

There probably needs to be a seperate directory where all fixfiles are stored, because reserving a directory name like fixes is not hard make this configurable in the modfile with a new directive like fixdir.

The fixfiles should be normal go files, but they probably need a standard layout (version, affected subpackage, description), therfore a go fix new command.

Go-ruleguard provides some capabilities for detecting and rewriting deprecated APIs. A more powerful language (starlark?) might make more complex rewrites possible.

This proposal doesn't seem to add anything beyond #32816: if we have cmd/fix, we can "allow third party packages to migrate" using go it. (And I hope we will, when that's possible.) So I think we should close it.