Background

I found the following criticism of Go language here: https://www.quora.com/What-reasons-are-there-to-not-use-Go-programming-language?share=1

Several points are mentioned, but the one that caught my eye is the following:

Types always implement interfaces implicitly; you just give your type methods that happen to have the same names, arguments, and return values as the interface in order to implement it.
Also, you can't overload functions or methods.
Neither of these two are particularly bad on their own. Indeed, either one on its own poses at worst a minor inconvenience. However, the consequence of having both in the same language creates the very real danger of being unable to use useful or possibly necessary libraries (e.g. your Go code needs to interact with some other service your company uses, and the only way to do that is with a Go library that team wrote).
The sneaky thing about implicitly implemented interfaces is that the interface's methods' names effectively transcend all namespaces. And that's particularly problematic due to Go's love of short, generic method names like Read() and New() and Create(). This is a global namespace name collision bug -- you know, the kind the rest of the software industry has been rid of for several decades.
For example, let's say I have two third-party packages, foo and bar. I want to make a type that implements both foo.Foo and bar.Bar.
foo.Foo is an interface that requires a method Copy() Foo,
and bar.Bar is an interface that requires a method Copy() (Bar, error).
Upon seeing this, I know I'm screwed. I can't overload a method called Copy() on my type, so I can never satisfy both interfaces. I simply can't continue, and for reasons that are entirely out of my hands. The best I can do is define a pair of types, one that implements foo.Foo and one that implements bar.Bar, and interveave their operation in some hideous, hacky way.

I thought this could perhaps be fixed by putting two structs that implement the two interfaces together in one struct, however doesn't quite work out nicely. See the following example:

package main

type Fooer interface {
	Foo() int
}

type Fooer2 interface {
 	Foo() string
}

type DoFoo1 struct {
}

type DoFoo2 struct {
}


func (DoFoo1) Foo() int {
	return 400
}

func (DoFoo2) Foo() string {
	return "Foo"
}

type DoFoo struct {
	DoFoo1
	DoFoo2
}

var _ Fooer = DoFoo1{}
var _ Fooer2 = DoFoo2{}
var _ Fooer = DoFoo{}
var _ Fooer2 = DoFoo{}

func main() {
}

https://play.golang.org/p/Q6Vwpb019-6

The compiler complains:

./prog.go:33:5: DoFoo.Foo is ambiguous
./prog.go:33:5: cannot use DoFoo literal (type DoFoo) as type Fooer in assignment:
	DoFoo does not implement Fooer (missing Foo method)
./prog.go:34:5: DoFoo.Foo is ambiguous
./prog.go:34:5: cannot use DoFoo literal (type DoFoo) as type Fooer2 in assignment:
	DoFoo does not implement Fooer2 (missing Foo method)

Proposal

In this case, there is no actual ambiguity, in because the signature of the two Foo functions is different. The Foo from DoDoo1 implements Fooer, and the Foo from DoFoo2 implements Fooer2. The code above should work. The compiler should automatically select the correct function based on the type signature of the methods to resolve the ambiguous name. Only if none of the candidates has required type signature, or if there are several with the required signature, then the compiler should raise an error. This would then also address the main criticism of interfaces I cited above.

This is not just a theoretical issue, there are indeed cases where it's hard to implement two different interfaces, normally from different packages, with one type, because there are name clashes.

Proposal template

• Would you consider yourself a novice, intermediate, or experienced Go programmer?
  I am experienced, I have been using Go for 10 years since before v1.0.
• What other languages do you have experience with?
  Batch files, Basic, C, C++, D, Java, Javascript, Lua, Objective-C, Oberon, Pascal, PHP, Python, R, Ruby, Shell scripts, Visual Basic, ...
• Would this change make Go easier or harder to learn, and why?
  It would not make Go easier to learn, but also not harder. It is something a novice might reasonably consider that it should work.
• Has this idea, or one like it, been proposed before?
  AFAIK, no.
• Who does this proposal help, and why?
  This proposal would help people who like the person criticising go would like to satisfy two different interfaces which have methods that have the same names but different signatures. .
• Is this change backward compatible?
  Yes, currently this is a compilation error. This proposal is to loosen an existing restriction.
• Show example code before and after the change.

Before:
The code above can be made to work by selecting a member of the DoFoo struct to satisfy one of the interfaces.

var df = DoFoo{}
var _ Fooer = df.DoFoo1
var _ Fooer2 = df.DoFoo2

After:
The compiler automatically select the sub-struct that correctly implements the interface.

var df = DoFoo{}
var _ Fooer = df // gets assigned to df.DoFoo1 automatically
var _ Fooer2 = df // gets assigned to df.DoFoo2 automatically

This would also work for functions with interface parameters.

• What is the cost of this proposal? (Every language change has a cost).
  The new compiler feature has to be implemented, documented and tested.
  • How many tools (such as vet, gopls, gofmt, goimports, etc.) would be affected?
    The gopls tool may or may not have to be updated to know about this new feature.
  • What is the compile time cost?
    Low, the compiler has at do a few extra field look ups, but it should already have that data available.
  • What is the run time cost?
    None.
• Can you describe a possible implementation?
  At compile time the compiler selects the sub-struct that satisfies the interface automatically. I think this should be relatively easy to implement.
• How would the language spec change?
  "Interface types" needs to be amended to specify this new feature of the language.
• Orthogonality: how does this change interact or overlap with existing features?
  It extends the current interface feature in a small but useful way.
• Is the goal of this change a performance improvement?
  No.
• Does this affect error handling?
  Not directly, apart from the fact that error is an interface.
• Is this about generics?
  No.