3

I was writing a program that reads data from a io.Reader and caches them in a bytes.Buffer.

type SecureReader struct {
    pipe      io.Reader
    shared    *[32]byte
    decrypted bytes.Buffer
}

func (s SecureReader) Read(b []byte) (int, error) {
    s.decryptPipeIntoBuffer()
    return s.decrypted.Read(b)
}

func (s SecureReader) decryptPipeIntoBuffer() (int, error) {/*Lots of code...*/}

I first used a value receiver, because I thought they were the same. However, I noticed my method does not do anything when invoked: SecureReader.Read() would always return io.EOF.

I banged my head around and changed the receiver type to

func (s *SecureReader) decryptPipeIntoBuffer() (int, error) {/*Lots of code...*/}

Now my code magically works. What is going on?

Some Noob Student
  • 14,186
  • 13
  • 65
  • 103

1 Answers1

3

A value receiver operates on a copy of the SecureReader instance s.

If the method mutates any part of the copy of the instance (like modify s.decrypted), it is not visible on the original instance of the receiver, once the method exit.

That changes with a pointer receiver, where the method operates and can mutates the actual SecureReader instance s, since a copy of the pointer is passed to the method.

See more examples in "Don't Get Bitten by Pointer vs Non-Pointer Method Receivers in Golang".

Simply stated: you can treat the receiver as if it was an argument being passed to the method. All the same reasons why you might want to pass by value or pass by reference apply.

Reasons why you would want to pass by reference as opposed to by value:

  • You want to actually modify the receiver (“read/write” as opposed to just “read”)
  • The struct is very large and a deep copy is expensive
  • Consistency: if some of the methods on the struct have pointer receivers, the rest should too. This allows predictability of behavior

If you need these characteristics on your method call, use a pointer receiver.

VonC
  • 1,262,500
  • 529
  • 4,410
  • 5,250
  • Does this mean every time I call Read() a new SecureReader would be passed in? Why would io.Reader impose such an awkward restriction? – Some Noob Student Apr 05 '15 at 22:10
  • 1
    @SomeNoobStudent an interface includes a pointer to the data, so copying an interface isn't a big deal. Copying a struct, in other hand, is, as it prevents mutability. – VonC Apr 05 '15 at 22:17
  • OH! How enlightening! Thank you so much! Showering you with upvotes. – Some Noob Student Apr 05 '15 at 22:20
  • Is it possible for some methods to have a reference as the receiver, and others to have an instance? I mean, if I need a struct to implement a certain interface, then some methods may be "read", and others may be "write". If this is not possible, having instance methods would appear like a really bizarre language feature. – Sassa NF Dec 31 '18 at 10:19
  • I think it is technically possible, but consistency is key. – VonC Dec 31 '18 at 10:34