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

spec: Clarify semantics of interface to interface assignment #5288

Open
DanielMorsing opened this issue Apr 14, 2013 · 10 comments

Comments

@DanielMorsing
Copy link
Contributor

commented Apr 14, 2013

When assigning an interface to an interface, the dynamic value of the LHS becomes the
dynamic value of the RHS, but this is not stated anywhere in the spec.

This came up in a discussion I had with a developer who was confused because he could
not use the reflect package to find the method set of an interface. He believed that the
interface{} parameter of reflect.TypeOf should have contained the static type of his
typed nil interface.
@cznic

This comment has been minimized.

Copy link
Contributor

commented Apr 15, 2013

Comment 1:

I think it's a simple value assignment once one assumes that
type RuntimeInterface struct { /* filtered or unexported fields */ }
Per analogiam, I don't think that the len() and cap() of LHS in `sliceL = sliceR` are
specified to become the "dynamic" values of the RHS. Neither for strings etc.
IMO #WorkingAsIntended
@DanielMorsing

This comment has been minimized.

Copy link
Contributor Author

commented Apr 15, 2013

Comment 2:

I don't think you can make the comparison between slices/strings and interfaces. The
assignment of interfaces include an implicit conversion that isn't present on
slice/string assignments.
For example, you can assign an io.WriteCloser to an io.Writer without a cast, even
though they are 2 different types.
@cznic

This comment has been minimized.

Copy link
Contributor

commented Apr 15, 2013

Comment 3:

@2: Ah, you're right, the type field is actually not always just copied as it would be
in a simple assignment.
@minux

This comment has been minimized.

Copy link
Member

commented Apr 15, 2013

Comment 4:

i think this essentially boils down to the fact that the dynamic type
of interface value will never be another interface.
@griesemer

This comment has been minimized.

Copy link
Contributor

commented Oct 10, 2013

Comment 5:

Owner changed to @griesemer.

@rsc

This comment has been minimized.

Copy link
Contributor

commented Nov 27, 2013

Comment 6:

Labels changed: added go1.3maybe.

@rsc

This comment has been minimized.

Copy link
Contributor

commented Dec 4, 2013

Comment 7:

Labels changed: added release-none, removed go1.3maybe.

@rsc

This comment has been minimized.

Copy link
Contributor

commented Dec 4, 2013

Comment 8:

Labels changed: added repo-main.

@griesemer

This comment has been minimized.

Copy link
Contributor

commented Nov 21, 2016

We should try to clarify this soon - it's central to Go. The language around interfaces - while intuitively mostly clear - is imprecise in various ways.

  • There's an almost circular definition of what an interface is: The section on interface types refers to the method set specified by the interface and calls it "its interface". The section on method sets defines the method set of an interface as its interface. We don't actually say what the method set is (though it's intuitively clear).

  • The section on assignability should be clearer about what assignment of an interface to another interface means.

  • Perhaps the definition of "implements" needs to be clarified.

When clarifying this, confirm that #17991 is adequately covered (an any other open issues in this space).

@bradfitz

This comment has been minimized.

Copy link
Member

commented Jan 3, 2017

Bumping to Go 1.9, but feel free to send a CL this week for Go 1.8 if you want.

@bradfitz bradfitz modified the milestones: Go1.9, Go1.8Maybe Jan 3, 2017

@griesemer griesemer modified the milestones: Go1.9Maybe, Go1.9 Jun 6, 2017

@ianlancetaylor ianlancetaylor modified the milestones: Go1.10, Go1.9Maybe Aug 2, 2017

@rsc rsc modified the milestones: Go1.10, Go1.11 Dec 14, 2017

@ianlancetaylor ianlancetaylor modified the milestones: Go1.11, Unplanned Jun 28, 2018

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
8 participants
You can’t perform that action at this time.