Proposal: allow exported fields in interfaces (Go2)

[ghasemloo]

Summary:
I propose allowing interfaces to have exported fields, e.g.

type I interface {
  X int
}

1. Background:
   The go way of setting fields in a struct is to directly access them. E.g. if we have a struct like

   type S struct {
     X int
   }
   

   we do not define setter and getter methods for X, we use .X to directly set and get X. E.g. protobuf code generated for go does not have setters and getters for their fields (unlike other languages).
   Consider a function that needs to access a field:

   func F(s S) {
     s.X = 5
   }
   

   If want to use F with other strucutes but the obvious way is to accept an interface

   func F(i I) {
     i.X = 5
   }
   

   but this doesn't work because we cannot have an interface with a field.

2. Proposal:
   Allow interfaces to have fields.

3. Impact:
   Code using reflection on interface types might be effected when the extended interfaces are passed to them. Otherwise there should not be an effect on existing code.

4. Discussion:
   Interfaces correspond to behavior. Either fields are not part of behavior of objects in which case we should be using setters and getters like other languages or they are part of the behavior in which case we should treat them as such and allow them in interfaces.

5. Alternatives:

• Alternative 1: use reflection (too much complexity to do something very simple, has the drawbacks of using reflection).
• Alternative 2: define interfaces with setters/getters

  type I interface {
    SetX(int)
  }
  

  and define setter and getter methods for each struct:

  func (s *S) SetX(x int) {
    s.X = x
  }
  

  If the type is defined in another package we would need to redefine it as a new type.

6. Implementation: TBD.

[bradfitz]

Sorry, Go isn't making language changes at this time. The language was pretty frozen at Go 1.0, and has become increasingly frozen with each release.

I'll tag this LanguageChange for future consideration for any Go 2.0 where it can be considered together with all other language change proposals. (Go doesn't do ad hoc language changes without considering how they all interact together) There have been similar proposals in the past, though. I seem to recall one where the proposer named them "data faces" or something, but I can't find it back now. Maybe somebody else has a link.