Comment 1:

Which String method gets called when I do
var x IJ // using first definition
fmt.Println(x.String())
The resolution of the ambiguity is why the second version of IJ works.

Comment 2:

But does that matter?  You could choose one arbitrarily and the effect would be the same.

Comment 3:

Labels changed: added release-none, languagechange.

Owner changed to @griesemer.

Comment 4:

There's no ambiguity at all. IJ is a interface but not a struct, so no real method is
duplicated.

Comment 5:

Status changed to LongTerm.

Comment 6:

Labels changed: added repo-main.

Comment 7 by SRabbelier:

Note that even if you factor out the common method into its own interface it doesn't
work:
type C interface { String() string }
type CI interface { C; f()  }
type CJ interface { C; g() } 
type CIJ interface { CI; CJ }
http://play.golang.org/p/r5yOykMn-a
prog.go:8: duplicate method String

Comment 8:

Re: #7: you didn't factor out the common method in CIJ - both CI and CJ have the String
method and hence the same issue.
Factoring out a common method set will work.

Say struct SI implements I, struct SJ implements J, and struct SIJ implements IJ,

OI := struct SI{} 
OJ := struct SJ{}
foo := struct SIJ{
    I: OI,
    J: OJ,
}

In this case, GO doesn't know which String() is the right method to invoke.
But if you explictly implement the common method(s) of the interfaces, it works.

@geterns You're example is confusing and syntactically incorrect (did you mean SI := struct { I }, etc.?). Either way, the proposal is about overlapping interfaces and the resulting interface - structs are not related to this except that a struct may implement an interface. How that interface came to be is unrelated at that point.

@griesemer Yes, I'm sorry about the mistask. My example is about combining interfaces with duplicate method(s) in a struct - by explictly implementing the common method(s) of interfaces for the struct, it works. However, combining interfaces with duplicate method(s) to get a new interface is still not working :(
Thanks for your reminding, they're not the same case.

@geterns This is a long-term issue and a language change (although backward-compatible). It's unimportant (though not hard to implement) and thus likely won't be addressed anytime soon. Regarding your other comments about combining interfaces in a struct: embedding in structs is different from embedding in interfaces - conflicts are only reported if access is ambiguous in the struct case.

I'd love to see this fixed. Interfaces is Go are pretty awesome and this is a fly in the ointment. I wonder what the original justification was for generating errors under these conditions? As long as the overlapping method signatures are identical I can't imagine why you'd ever want the compiler to flag this as an error.

It's unimportant (though not hard to implement) and thus likely won't be addressed anytime soon.

FWIW, I just filed a dup (#15666) on behalf of a friend for whom this was causing considerable frustration.

Perhaps we should try to address this for 1.8. It seems pretty straightforward and incontroversial. Anybody having good counter arguments why this might be a mistake?

Just to explain how this comes up in real life: I tend to abstract away the data layer from the business layer so a) I can easy make mocks for tests, and b) I can have flexibility in changing data providers, sharding data, etc. Typical interface might be:

package user

type Database interface {
    GetAccount(accountID uint64) (model.Account, error)
}

So then I have some other packages that want to be able to fetch accounts under some circumstances, so they say they require their Database to have all of user's Database methods:

package hardware

type Database interface {
    user.Database
    SaveDevice(accountID uint64, device model.Device) error
}

package wallet

type Database interface {
    user.Database
    ReadWallet(accountID uint64) (model.Wallet, error)
}

Then, I have some package that needs both of those packages, and its Database interface looks like:

package shopping

type Database interface {
    wallet.Database
    device.Database
    Buy(accountID uint64, deviceID uint64) error
}

And then, kablooey: Duplicate method GetAccount(accountID uint64) (model.Account, error)

Would be neat if this was fixed, since it seems straight forward and non controversial. I run into it regularly and have to resort to copy-pasting method signatures.

I think it's OK but I find it all a bit confusing. The clarity of "no duplicates" is comforting.

surely if two interfaces include the same sub-set of methods, that’s telling you there is a lower level 'thing' that should have its own interface, having this an error means smaller (flexible) interfaces, I’d have thought this was spot-on for Go, doesn't the problem come from inheritance thinking?

But does that matter? You could choose one arbitrarily and the effect would be the same.

Type-equivalence does not always mean semantic equivalence. There are plenty of interfaces with additional behavior requirements that the compiler is not aware of. In a perfect world, all behavior would be specified in the type system, but this is not the case.

In a pretty good world, developers would register their interfaces through a common query system and immediately deprecate colliding interfaces for distinct interfaces. Maybe something like Hoogle for Go interfaces?

Meanwhile, a mechanism for disambiguation would be nice.

Leaving open for a week for final comments.

Something I thought of: what's the expected behavior when go 1.13 module A depends on go 1.14 module B, and B makes use of overlapping interfaces or changes its exported interfaces in a way that cause A to make use of them? Two specific cases:

1. Is it okay for B to export a defined interface type that uses overlapping interfaces, and for A to consume that type? (I assume yes, though I think this currently doesn't work.)

2. Initial state: module B exports type X interface{}; type Y interface{} and module A has type I interface { B.X; B.Y }. If B upgrades to go 1.14 and adds M() to both B.X and B.Y, should module A build even if it stays on go 1.13? (I'm leaning towards no, but not sure.)

1. Is it okay for B to export a defined interface type that uses overlapping interfaces, and for A to consume that type?

It should be, yes: since the method sets are identical and the go version for B permits overlapping interfaces, it should not be a breaking change for the maintainer of B to replace

interface FooBarrer {
	Foo()
	Bar()
}
interface BarBagger {
	Bar()
	Bag()
}
interface FooBarBagger {
	Foo()
	Bar()
	Bag()
}

with

interface FooBarrer {
	Foo()
	Bar()
}
interface BarBagger {
	Bar()
	Bag()
}
interface FooBarBagger {
	FooBarrer
	BarBagger
}

2. […] If B upgrades to go 1.14 and adds M() to both B.X and B.Y, should module A build even if it stays on go 1.13? […]

No. The package combining the two interfaces is A, and the go version for A does not permit that package to embed overlapping interfaces.

The maintainer of B has made a breaking change by adding a method to an exported interface, so the fact that this breaks A should not come as a surprise.

Specifically, the change to either interface would also break A if they had previously defined:

type I interface {
	B.X
	B.Y
	M() someOtherType
}

What about:

package a // go 1.14

type a1 { interface A() }
type a2 { interface A() }
type A = interface { a1; a2 }

package b // go 1.13

import "./a"

var _ a.A

That specific example won't work, because the go 1.13 directive is in the go.mod file and relative imports aren't allowed in module mode. 😛

But putting that aside, the var _ a.A should be allowed, because the package that actually combines the two interfaces is a, not b.

That specific example won't work, because the go 1.13 directive is in the go.mod file and relative imports aren't allowed in module mode. stuck_out_tongue

Ack. I don't understand Go modules well enough to know how to concisely write a test case that uses them directly, so I resorted to pseudocode.

But putting that aside, the var _ a.A should be allowed, because the package that actually combines the two interfaces is a, not b.

This is my inclination as well.

I've submitted b7d097a. As of master, cmd/compile applies these rules for overlapping interfaces:

• An interface type literal is allowed to embed overlapping interfaces if its source form appears in a package compiled with -lang=go1.14 or newer.
• Between packages, types are only distinguishable up to identity. Since for any interface type literal that uses overlapping interfaces, there's always an identical type literal that does not require overlapping interfaces, importers are unaffected by those internal choices of the other package.

No objections raised, so accepting.

Already implemented, so closing.

Change https://golang.org/cl/214240 mentions this issue: compiler: permit duplicate methods from embedded interfaces

Change https://golang.org/cl/216997 mentions this issue: doc/go1.14: document overlapping interfaces change (update release notes)

Change https://golang.org/cl/217134 mentions this issue: go/types: unexport Checker.LookupFieldOrMethod