Current behavior

Currently for a function to satisfy an interface, the signature of the function has to match the interface signature exactly.
In the case where the interface signature says the function should return an interface, the function can only return that interface, and not another interface which is a superset.

Meaning if you have the interfaces:

type ReaderOpener interface {
  Open() io.Reader
}
type ReadSeekerOpener interface {
  Open() io.ReadSeeker
}

Then the following type would satisfy ReadSeekerOpener, but not ReaderOpener.

type MyStruct struct {}
func (ms MyStruct) Open() io.ReadSeeker {}

Attempting to use MyStruct to satisfy ReaderOpener results in:

cannot use MyStruct literal (type MyStruct) as type ReaderOpener in assignment:
	MyStruct does not implement ReaderOpener (wrong type for Open method)
		have Open() io.ReadSeeker
		want Open() io.Reader

Proposal

The proposal is to allow functions returning an interface to satisfy the interface if the function returns an interface which is a superset of the one being satisfied.

Meaning that in the above code, MyStruct would satisfy both ReadSeekerOpener and ReaderOpener.

Now there is one particular about how "superset" is defined. It could either be 2 completely different interfaces with no inheritance, or one interface could be a composition containing the other.
Meaning:

type Reader interface {
  Read([]byte) (int, error)
}
type ReadSeeker {
  Read([]byte) (int, error)
  Seek(int64, int) (int64, error)
}

vs.

type Reader interface {
  Read([]byte) (int, error)
}
type ReadSeeker {
  Reader
  Seek(int64, int) (int64, error)
}

The key difference being that the latter ReadSeeker interface embeds the interface required in the ReaderOpener Open() signature.

While I think it might be nice if both would satisfy the proposed rule, if it matters, I think it would be reasonable to allow the latter to satisfy the proposal, but not the former.

Additional considerations

Explicit types

There's also the related case of an explicit type:

type ReaderOpener func() io.Reader

and whether a function which returns io.ReadSeeker should be assignable to a variable of this type.

I don't know that this needs to be addressed in this proposal, but I mention it as it seems related.

Function argument subsets

In theory the return superset logic should be able to be applied to function arguments, and whether interfaces can be subsets. Meaning whether a function with the signature func(io.Reader) should satisfy interface { func(io.ReadSeeker) }. In theory since the function only needs io.Reader, if it's given io.ReadSeeker, it should be able to operate normally.
So the consideration is that if return values are relaxed to allow interface supersets. Should function arguments be relaxed to allow interface subsets?