My opinion is we can make good use of go fix.

Suppose there is a 'table' for standard packages at "$GOROOT"/RENAME:

$ cat "$GOROOT"/RENAME
# This file could be used for `go fix`
[package]
x/net/context=context
[type]
io.ByteBuffer=bytes.Buffer

$ go fix -rename "$GOROOT"/RENAME [packages]
# -- or --
# use a standard libraries rename table as default
$ go fix -rename [packages]
# -- or --
# include this fix as default
$ go fix [packages]

It's great if godoc can interpret them. Perhaps the 'table' can be written in some format of comment for godoc?

Any thoughts?

cc: @rsc

This sounds like something better left to release notes.

I agree this is a very attractive idea, but it's unlikely to be effective in practice. Your conversions will need to cover all possible uses. Also, if you change semantics but not the API that might mean other surrounding code would need to differ and not the specific call to your code.

@LionNatsu Typically proposals give a concrete design rather than something like "go should have generics". If you want to float an idea I'd recommend taking it to https://github.com/golang/go/wiki/Questions .

In this case I don't see a concrete proposal, but an idea.

If you'd like to pursue this I would recommend you try to discover methods of doing this, then make it easy for other package maintainers to do it as well. Share it with a few others and revise your design. After you do that feel free to make a concrete proposal with your design.

I'm not trying to dismiss your suggestion; Go has a way to detect API breakages for releases. It has also been suggested in the context of vendoring discussions. Elm has a way to do this too. It may be a good idea. But I havnen't seen a good implementation with a generally useful outcome. That's what this would need to solve before it could proceed.

Reopening. It's true that this is not a concrete, specific proposal, but I do think it's something we should be thinking about and discussing. Much #18130 discussed the problem and solution space before specific solutions, I think that would help here too. This may be open for a long time before we settle on something - it's not on anyone's front burner - but in the long term I believe it will be an important part of how we manage breaking changes in large code bases (along with semantic versioning and fixing other rough spots, like with type aliases).

A table alone isn't enough in many cases. You will need a Turing complete program. Much like we have the vendor subdir, why not have an fix subdir with an fix package that programatically performs the upgrade? Or, like for go test, have files with a _fix.go suffix? Some kind of standard API needs to be defines, as for go test, but I'll leave that up to the experts.