proposal: Go 2: global interning of equivalent interfaces in the program

[Jorropo]

Problem:

I recently refactored some code (moving a bunch of multi repos modules into a mono repo one), which gave me this solution:

// --- old module
type SomeInterface interface {
    DoStuff()
}

// --- new module (in the monorepo)
type SomeInterface interface {
    DoStuff()
}

// --- a third module (I actually have close to a hundred different modules like this)
type SomeProducerInterface interface {
    Get() old.SomeInterface
}

// --- a consumer module
func Use(SomeProducerInterface) { /* ... */ }

// --- an implementation, that I refactored to use the new API (this is also in the monorepo)
type impl struct{}
func (impl) Get() new.SomeInterface {
    return nil
}

consumer.Use(impl{}) // does not compile:
/*
 ./prog.go:28:13: cannot use impl{} (value of type impl) as type third.SomeProducerInterface in variable declaration:
	impl does not implement third.SomeProducerInterface (wrong type for Get method)
		have Get() new.SomeInterface
		want Get() old.SomeInterface
*/

// other example:
type SomeProducerInterface interface { // new equivalent definition of SomeProducerInterface but in the monorepo
    Get() old.SomeInterface
}
var _ third.SomeProducerInterface = SomeProducerInterface(nil) // does not compile

Current workarounds:

1. Remove all usage of the old interface definition within the program.
   Not Possible for me (prevents me from doing incremental refactors).
2. Create stub types and update the old module. (tedious but work, my current solution)
   My main complain with this is that my new monorepo librairy does not consume all of the stubs, so sometime consumers see unexpected types errors when they upgrade my monorepo and they have to manually go get all packages that have been stubbed to use the stubs too.

Solution:

As a solution I propose that for all sets of "compatible types", the compiler picks one of them and use it in all usage of the other compatible types in the set within the program.

Two types are said to be compatible:

• if they are interfaces, they both need to have the same methods and for all methods arguments and return types need to be compatible in order to be considered compatible, for cyclic case of this definitions it is considered compatible.
• for everything else, the types have to be the same (current rules).

TODO: Should the behaviour of which type of the compatible set is picked be defined in the spec ?
This would ensure consistency across compiler.

Non breaking changes:

Programs like shown above will now compile.

Breaking changes:

Interfaces types gotten through reflect may now point to other (compatible) interfaces unexpectedly.
So things like this would give a different answer:

package main

import (
	"fmt"
	"reflect"
)

type A interface {
	DoStuff()
}

type B interface {
	DoStuff()
}

type impl struct{}

func (impl) Get() A {
	return nil
}

func main() {
	t := reflect.TypeOf(impl{}).Method(0).Type.Out(0)
	// Right now t is certain to be A
	// But after the change it may be interned to B
	fmt.Println(t.Name())
}

[earthboundkid]

The canonical solution to this problem is

package old

import "newpkg"

type SomeInterface = newpkg.SomeInterface

A different solution is to use generics.

func DoThing[I DoStuff()](fn func() I) {
   // ...
}

[seankhliao]

Please fill out https://github.com/golang/proposal/blob/master/go2-language-changes.md when proposing language changes

[Jorropo]

@carlmjohnson the first solution is already what I am doing already, it requires manual work:

Create stub types and update the old module. (tedious but work, my current solution)

The second solution requires updating consumers (again work) and make code quality suffer.

Interning interfaces I think also make sense from a language design.
In go everything teaches you that interfaces are transparent, types implicitly convert to narrower or matching interfaces.
However this case I've described is the only case (*I know about) where interfaces are not transparent.

[earthboundkid]

I couldn't find the issue with a quick "site:github.com/golang/go/issues" search, but there is an ancient issue from the early days of Go discussing this problem. If it could be solved easily, it would have been solved by now.

[seankhliao]

Duplicate of #7512