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

Jump to bottom

proposal: spec: use zero receiver for value method invoked via nil pointer #18775

Closed
rogpeppe opened this issue Jan 24, 2017 · 5 comments
Closed

proposal: spec: use zero receiver for value method invoked via nil pointer #18775

rogpeppe opened this issue Jan 24, 2017 · 5 comments
Labels
NeedsDecision Feedback is required from experts, contributors, and/or the community before a change can be made. Proposal v2 A language change or incompatible library change
Milestone
Proposal

Comments

@rogpeppe
Copy link
Contributor

Currently, if a method is defined on a value type, that method is also
part of the method set of the pointer type. However, if that method
is called on the nil pointer, it panics.

This means there's no way to define a method that works on all possible
values and pointer values for a type.

I propose that when a value method is called on a nil pointer, instead of panicking,
the method is invoked on the zero value for the type.

As this breaks code that currently relies on catching this panic (notably the
fmt package), it is probably sufficiently backwardly incompatible to justify
the Go2 tag.
@rogpeppe rogpeppe added the v2 A language change or incompatible library change label Jan 24, 2017
@rogpeppe rogpeppe mentioned this issue Jan 24, 2017
Open
@go101
Copy link

go101 commented Jan 25, 2017

Why? Looks not reasonable.

@mvdan
Copy link
Member

mvdan commented Jan 25, 2017

@golang101 this way you can handle a nil pointer in a single place instead of many.

Flipping the question - what makes this not reasonable for a potential Go 2?

@gopherbot gopherbot added this to the Proposal milestone Mar 20, 2017
@rsc rsc changed the title proposal: make value method work when called on nil pointer proposal: spec: make value method use zero receiver when called on nil pointer Jun 16, 2017
@rsc rsc changed the title proposal: spec: make value method use zero receiver when called on nil pointer proposal: spec: use zero receiver for value method invoked via nil pointer Jun 16, 2017
@ianlancetaylor ianlancetaylor added the NeedsDecision Feedback is required from experts, contributors, and/or the community before a change can be made. label Jan 23, 2018
@bcmills
Copy link
Contributor

bcmills commented Nov 16, 2018

this breaks code that currently relies on catching this panic (notably the
fmt package)

See also #28150.

@ianlancetaylor
Copy link
Contributor

If we adopt this it would change the behavior of existing code. That is, the exact same code would compile and run before and after making this change to the language, but it would behave differently. That makes it difficult to implement according to the guidelines at https://github.com/golang/proposal/blob/master/design/28221-go2-transitions.md . I'm not sure the benefit of making this change is worth the cost of having the same code behave differently in different versions of Go.

@gopherbot gopherbot removed the NeedsDecision Feedback is required from experts, contributors, and/or the community before a change can be made. label Aug 16, 2019
@gopherbot gopherbot added the NeedsDecision Feedback is required from experts, contributors, and/or the community before a change can be made. label Sep 3, 2019
@rogpeppe rogpeppe mentioned this issue Aug 24, 2020
Open
@ianlancetaylor
Copy link
Contributor

Thanks, but there isn't enough benefit here to change the behavior of existing code. Closing.

@ianlancetaylor ianlancetaylor closed this as not planned Won't fix, can't repro, duplicate, stale Aug 23, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
NeedsDecision Feedback is required from experts, contributors, and/or the community before a change can be made. Proposal v2 A language change or incompatible library change
Projects
None yet
Milestone
Proposal
Development

No branches or pull requests
6 participants
@rogpeppe @ianlancetaylor @mvdan @bcmills @gopherbot @go101