Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

proposal: allow duplicate methods in interfaces #15666

Closed
josharian opened this issue May 12, 2016 · 4 comments
Closed

proposal: allow duplicate methods in interfaces #15666

josharian opened this issue May 12, 2016 · 4 comments

Comments

@josharian
Copy link
Contributor

josharian commented May 12, 2016

This is a proposal for a minor, backwards-compatible language change.

Currently, all methods in an interface type must have different names. The spec says:

As with all method sets, in an interface type, each method must have a unique non-blank name.

This means that both these interfaces are disallowed:

type Dup interface {
    F()
    F()
}

type NotDup interface {
    F()
    F() int
}

The proposal is to allow interfaces to have non-unique names as long as the method signature is identical for all methods with the same name, that is, to allow duplicate methods. Type Dup above would be allowed, but type NotDup would not. For the purposes of type identity, interface satisfaction, etc., duplicate methods in an interface would be treated as if they occurred exactly once.

This arises in practice when embedding interfaces. Consider:

type AI interface {
    A()
}

type BI interface {
    AI
}

type CI interface {
    AI
}

type DI interface {
    BI
    CI
}

Type DI is disallowed by the spec, even though it may be the most clear, concise, self-documenting, easy to maintain, DRY way to express the interface. To work around this, users must manually duplicate the contents of the interface.

This invites the response "just write the code!". But it is worth observing that these duplicated interfaces can be large and can occur spread across multiple levels and across multiple packages with multiple owners. More importantly, when changing one of the embedded interfaces, all copies must be changed, and there is no clear way to write a tool to safely do that, or even detect a problem, because the explicit link between the embedding and the embedded interface is gone.

I believe that the update to the spec would be minimal, and that the impact on compilers and typecheckers would be small and localized.

cc @hasty who has been repeatedly frustrated by this

cc @griesemer @ianlancetaylor @rsc @robpike @mdempsky @bradfitz to tell me why this is a terrible idea :)

@josharian josharian added this to the Proposal milestone May 12, 2016
@dsnet
Copy link
Member

dsnet commented May 12, 2016

Some previous discussion on #6977.

@josharian
Copy link
Contributor Author

Thanks, @dsnet. Now also cc @alandonovan. :)

@mdempsky
Copy link
Contributor

Should we close this as a dup then?

@josharian
Copy link
Contributor Author

I suppose so, although hopefully it'll trigger a second look at #6977. I'll at least drop one comment there.

@golang golang locked and limited conversation to collaborators May 12, 2017
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

No branches or pull requests

5 participants