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: disallow type P *T if T has methods #8590

Closed
griesemer opened this issue Aug 25, 2014 · 5 comments
Closed

proposal: spec: disallow type P *T if T has methods #8590

griesemer opened this issue Aug 25, 2014 · 5 comments
Labels
FrozenDueToAge LanguageChange 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

@griesemer
Copy link
Contributor 

We already disallow named pointer types as types of receivers or anonymous fields. We
may want to consider outlawing them more generally since they have some strange
properties because methods do not automatically indirect pointers, while fields do.

Here's an example: http://play.golang.org/p/BsThM7_Jcd

When we see p.m we don't know if p should be automatically indirected unless we know
that m is a field. Since we (a compiler/typechecker) cannot know this w/o looking it up
first, for fields it is necessary to do a 2nd lookup if the first one (w/o indirection)
finds nothing. If the 2nd lookup results in finding a method (rather than a field), it
must be discarded.
@griesemer
Copy link
Contributor Author

Comment 1:

Owner changed to @griesemer.

Status changed to LongTerm.

@griesemer
Copy link
Contributor Author

Comment 2:

Labels changed: added release-none.

@griesemer griesemer added longterm v2 A language change or incompatible library change LanguageChange labels Aug 25, 2014
@griesemer griesemer self-assigned this Aug 25, 2014
@rsc rsc added this to the Unplanned milestone Apr 10, 2015
@extemporalgenome
Copy link
Contributor

Are there legitimate use cases for named pointer types? I have not seen them in the wild. Alternatively, perhaps we could disallow automatic dereference of fields "through" a named type like the above P -- this would make them unwieldy enough that people will avoid wanting to use them, for the same reason that defer recover() does not work (as it'd make panics too convenient).

@rsc rsc changed the title spec: disallow type P *T if T has methods proposal: spec: disallow type P *T if T has methods Jun 17, 2017
@griesemer griesemer mentioned this issue Sep 19, 2017
Open
@griesemer
Copy link
Contributor Author

There's of course type P *P which we perhaps don't want to lose...

@ianlancetaylor ianlancetaylor added NeedsDecision Feedback is required from experts, contributors, and/or the community before a change can be made. and removed LongTerm labels Jan 3, 2018
@ianlancetaylor ianlancetaylor modified the milestones: Unplanned, Proposal Jan 3, 2018
@griesemer
Copy link
Contributor Author

I'm going to withdraw this proposal for now. There's a lot of subtle interplay between method sets, pointer types, receiver base types, and field and method lookups. This will need a more thorough proposal if any.

@golang golang locked and limited conversation to collaborators Jan 3, 2019
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Assignees
No one assigned
Labels
FrozenDueToAge LanguageChange 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
@rsc @extemporalgenome @dmitshur @ianlancetaylor @griesemer @gopherbot