Copying or passing the pointer

I've seen recommendations to use the following in getters and setters, i.e. pass a pointer when you are setting the value in order to change the original data, but it's not required when getting the value.

In the case of a getter, without a pointer, the value is copied. My question is, isn't it inefficient to copy the object to get value out of it, could we not use a pointer as well?

type Foo struct {
     Body string
}

func (foo Foo) GetBody() interface{} {
	return foo.Body
}

func (foo * Foo) SetBody(body string) {
	foo.Body = body
}

Where did you see a recommendation to use a non-pointer receiver for getters ? I don’t think this is done in the official packages; e.g., the zip package definitely uses pointer receivers for both getters and setters.

func (h *FileHeader) ModTime() time.Time
func (h *FileHeader) Mode() (mode os.FileMode)
func (h *FileHeader) SetModTime(t time.Time)
func (h *FileHeader) SetMode(mode os.FileMode)

See also :

• Should I define methods on values or pointers?
• How to select a receiver type

Did you read the Go Frequently Asked Questions (FAQ)?

> Should I define methods on values or pointers?
>
> func (s *MyStruct) pointerMethod() { } // method on pointer
> func (s MyStruct) valueMethod() { } // method on value
>
> For programmers unaccustomed to pointers, the distinction between
> these two examples can be confusing, but the situation is actually
> very simple. When defining a method on a type, the receiver (s in the
> above examples) behaves exactly as if it were an argument to the
> method. Whether to define the receiver as a value or as a pointer is
> the same question, then, as whether a function argument should be a
> value or a pointer. There are several considerations.
>
> First, and most important, does the method need to modify the
> receiver? If it does, the receiver must be a pointer. (Slices and maps
> act as references, so their story is a little more subtle, but for
> instance to change the length of a slice in a method the receiver must
> still be a pointer.) In the examples above, if pointerMethod modifies
> the fields of s, the caller will see those changes, but valueMethod is
> called with a copy of the caller's argument (that's the definition of
> passing a value), so changes it makes will be invisible to the caller.
>
> By the way, pointer receivers are identical to the situation in Java,
> although in Java the pointers are hidden under the covers; it's Go's
> value receivers that are unusual.
>
> Second is the consideration of efficiency. If the receiver is large, a
> big struct for instance, it will be much cheaper to use a pointer
> receiver.
>
> Next is consistency. If some of the methods of the type must have
> pointer receivers, the rest should too, so the method set is
> consistent regardless of how the type is used. See the section on
> method sets for details.
>
> For types such as basic types, slices, and small structs, a value
> receiver is very cheap so unless the semantics of the method requires
> a pointer, a value receiver is efficient and clear.

When working with struct (like the above example), use pointers whenever as possible. I don't see anything wrong passing a struct as a pointer especially when you're not modifying its value. There's cases when u don't want to do mutation on your struct so to make sure you're not modifying anything, you're not gonna pass it as a value, but when performing read only it's more prefered to use pointers in this case