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: Go 2: allow interface pointer receivers #31146

Closed
zigazeljko opened this issue Mar 29, 2019 · 3 comments
Closed

proposal: Go 2: allow interface pointer receivers #31146

zigazeljko opened this issue Mar 29, 2019 · 3 comments
Labels
FrozenDueToAge LanguageChange Proposal v2 A language change or incompatible library change
Milestone

Comments

@zigazeljko
Copy link

What version of Go are you using (go version)?

$ go version
go version go1.11 linux/amd64

Currently, methods are not allowed to have an interface receiver or an interface pointer receiver. While methods with interface (value) receivers are clearly not possible, methods with interface pointer receivers (and consequently having interface pointers implement other interfaces) should be possible. This would be extremly useful for cases such as unmarshaling polymorphic JSON.

For example:

type MyInterface {
    ...
}

func (p *MyInterface) UnmarshalJSON(data []byte) error {
    *p = ...
}

var obj MyInterface
json.Unmarshal(data, &obj)
// &obj implements json.Unmarshaler
@gopherbot gopherbot added this to the Proposal milestone Mar 29, 2019
@ianlancetaylor ianlancetaylor changed the title proposal: spec: allow interface pointer receivers proposal: Go 2: allow interface pointer receivers Mar 29, 2019
@ianlancetaylor ianlancetaylor added LanguageChange v2 A language change or incompatible library change labels Mar 29, 2019
@ianlancetaylor
Copy link
Contributor

What if you write

type MyInterfaceWrapper struct {
    wrapping MyInterface
}

func (p *MyInterfaceWrapper) UnmarshalJSON(data []byte) error { ... }

var obj MyInterfaceWrapper
json.Unmarshal(&obj)
// pull out value from wrapping field

Just to clarify what you are proposing, is there anything this proposal permits that we couldn't do with an approach like that?

@zigazeljko
Copy link
Author

@ianlancetaylor I think not (apart from simplifying code in such cases).

@ianlancetaylor
Copy link
Contributor

Thanks, but since this proposal would make the relationship between interfaces and methods more confusing, and since it would not add functionality that we can't already get in other ways, we aren't going to move this forward with this proposal.

@golang golang locked and limited conversation to collaborators May 6, 2020
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
FrozenDueToAge LanguageChange Proposal v2 A language change or incompatible library change
Projects
None yet
Development

No branches or pull requests

3 participants