I'm not convinced by the case you motivate this with. ISTM that a change in foo.FooBarrer or bar.BarBazzer that would cause a conflict is a breaking change (as is any change to any public method of an exported interface, AFAICT). As such, foo or bar (whichever breaks) should bump their major version when doing that change. At that point, SIV means that FooBarBazzer still refers to the old version. Updating it to the types from the new major version is, again, a breaking change. All of these breakages are regardless of whether or not we allow conflicting method definitions. So maybe I misunderstand what you are getting at, but to me, this doesn't seem to really help in the situation you outline.

@Merovius

ISTM that a change in foo.FooBarrer or bar.BarBazzer that would cause a conflict is a breaking change (as is any change to any public method of an exported interface, AFAICT).

Correct: adding a method to an existing, exported interface is a breaking change. Part of the point of this proposal is to contain and isolate the damage from such a break.

As such, foo or bar (whichever breaks) should bump their major version when doing that change. At that point, SIV means that FooBarBazzer still refers to the old version.

Note that my example involves breaking changes in v0 releases, which do not require a major-version increment and thus do not require a semantic import path change.

We don't recommend making breaking changes like that, but they can sometimes be useful — especially during early development of a public package, or during ongoing development of packages with limited users (such as private code in use by multiple projects within an enterprise).

The other place where this may come up is in generic code, in which user-supplied type arguments may cause some generic interface to be unsatisfiable. If the unsatisfiable interface is only used as, say, an input to a method that the user does not intend to call, then the fact that it has no usable implementation is arguably not important.

This also parallels some of the discussion in #45346: if we argue that it isn't important to diagnose interfaces whose type-sets are empty due to conflicting concrete-type constraints, then why is it important that we diagnose interfaces whose type-sets are empty due to conflicting method constraints?

if we argue that it isn't important to diagnose interfaces whose type-sets are empty due to conflicting concrete-type constraints, then why is it important that we diagnose interfaces whose type-sets are empty due to conflicting method constraints?

FTR I wasn't arguing that it's "not important", but that the benefits are low compared to the complexity. It is not hard to detect if an interface is not satisfiable, but it's very hard to detect if a type set is empty :)

You can still do this today without any change to the language, see example below (removed imports so you can directly compile the code):

type FooBarrer struct{}
func (f *FooBarrer) fn() {
	
}

type BarBarrer struct{}
func (b *BarBarrer) fn() {
	
}

type FooBarBazzer interface {
	FooBarrer
	BarBarrer
}

type NewFooBarBarrer struct {
	FooBarBazzer
}
func (e *NewFooBarBarrer) fn() {
	e.FooBarBazzer.(*BarBarrer).fn()
}

The new NewFooBarBarrer implementation of FooBarBazzer calls BarBarrer's fn() function while both old and new implementations coexist.

GoLang doesn't need to add complex function/operation overloading, unlike other OO languages, it's focused on basic interface-implementation interactions to simplify APIs.

@Baha-sk, you can embed conflicting interfaces in a struct type today. However, you cannot do the same with an interface type. This proposal is to change the interface behavior to more closely match the struct behavior.

That's the whole point @bcmills, when overriding, you're doing it on the struct that specifies the implementation, not the interface.

Although FooBarBazzer embeds 2 conflicting implementations (or even interfaces), it's the implementation of it that decides which member to call.

For the sake of clarity, here's the updated example with embedded interfaces (and their respective implementations):

type Foo interface {
	fn()
}

type FooBarrer struct{}

func (f *FooBarrer) fn() {
	fmt.Println("old fn")
}

type Bar interface {
	fn()
}

type BarBarrer struct{}

func (b *BarBarrer) fn() {
	fmt.Println("new fn")
}

type FooBar interface {
	Foo
	Bar
}

func NewFooBarBarrer() FooBar {
	return &FooBarBarrer{
		Foo: &FooBarrer{},
		Bar: &BarBarrer{},
	}
}

type FooBarBarrer struct {
	Foo
	Bar
}

func (e *FooBarBarrer) fn() {
	e.FooBar.(*BarBarrer).fn()
}

FooBar doesn't care one bit how implementations call fn() as long as it's defined and can be resolved to a concrete implementation. Instantiating ForBarBarrer dictates which one to call.

If say the client has a function referencing FooBar like : CallMe(fb FooBar), then I don't expect the client to create a separate CallMe clone to specify which interface should call fn(). The client will be provided with an updated struct implementation (eg FooBarBarrer) that does the job for them.

I think you've missed the point of this proposal entirely, @Baha-sk. I believe this proposal isn't about being stuck on the details of concrete implementations, but rather about changing the language to make code like this compile and run as is.

Even though FooBarBazzer and bar_BarBazzer both have Fn() defined as a member function, they are not the same type definitions.

It's a mistake to allow swapping interface types in arguments or any field, this will introduce inconsistencies in the language.

I think the problem lies in the design of FooBarBazzer and OldF/NewF calls. Typically updating an API change will require clients to migrate from an old version to a newer one that's not backward compatible. That's part of life.

I think as much as we'd like public APIs not to break old clients when migrating, keeping the language clean and consistent is more important. The type struct -> interface relationship is well established and understood. Swapping of interfaces with same function definitions will require additional checks on the interface definition instead of just verifying the type.

For me, clarity and consistency overweigh seemless migration of APIs. Don't you agree?

That's just my 2 cents, I may be wrong and your case is probably a valid one, the Go Authors/Experts might have a stronger opinion.

This proposal suggests that we add complexity to the language in order to support a complex code base. While the language should support complex code bases, this seems like an inappropriate approach of adding complexity to the language rather than removing complexity from the code base.

Also there doesn't seem to be strong support for this proposal.

Therefore, this is a likely decline. Leaving open for four weeks for final comments.

No further comments.

I was writing parser for 3rd party schema which might not define fields for types (and even whole types) yet data provider still can send them.

Missing types isn't a problem since I could just add them to parent interface and embed generated one inside.

However, if there's field in existing type that isn't defined in schema, that leads to situation where I can't safely override interface method for new type that embeds old one.
Other options mostly look like janky workarounds: either add hardcoded replacements in generator or create new interface method for wrapper type.
Second option leaves unused method in interface that won't be used.

This looks somewhat like this:

// generated code

type SomeEvent struct {
    EventID string `json:"event_id"`
}

type generatedHandler interface {
    SomeEvent(SomeEvent)
}

var generatedDefs = map[string]reflect.Type{
    "some_event": reflect.TypeOf(SomeEvent{}),
}

func newEvent(name string) interface{} {
    return reflect.New(generatedDefs[name]).Interface()
}

// wrapper code

type SomeEventShim struct {
    SomeEvent
    AnotherField int `json:"another_field"`
}

type Handler interface {
    generatedHandler
    SomeEvent(SomeEventShim) // I'd like that
}

func init() {
    // so I can use that
    generatedDefs["some_event"] = reflect.TypeOf(SomeEventShim{})
}

// and that
type HandlerImpl struct {}
func (HandlerImpl) SomeEvent(SomeEventShim) {}