CODEWITHSUNDEEP
pointersgo
Karel Bílek
Karel Bílek

Reputation: 37724

Why does go standard library prefer pointer receivers?

Is there a reason why Go standard library prefers pointer receivers, even where value receivers would work?

For example, in go 1.14 io.multiwriter:

type multiWriter struct {
    writers []Writer
}

func (t *multiWriter) Write(p []byte) (n int, err error) {
...
}

...
func MultiWriter(writers ...Writer) Writer {
...
   return &multiWriter{allWriters}
}

This would work even if instead of &multiWriter{allWriters}, the function returned multiWriter value, and func (t *multiWriter) Write had a value receiver.

Is there a reason why go standard library consistently prefers pointer receivers?

Upvotes: 0

Views: 257

Answers (2)

Volker
Volker

Reputation: 42478

Is there a reason why go standard library consistently prefers pointer receivers

No.

Sometimes it's for compatibility reasons (e.g. because the first version would not have worked on value receivers). Sometimes it's for consistency reasons. Sometimes it's author preference. There is not much to see or learn here.

Upvotes: 1

mvdan
mvdan

Reputation: 536

multiWriter's methods could indeed skip the pointer receivers, but since MultiWriter returns an interface and interfaces in Go only contain a type and a pointer to the data, you would need to separately allocate a struct anyway.

One interesting point here is that, as far as I can tell, this is an implementation detail and not part of the spec. One could imagine an alternative Go implementation which uses a different representation of interfaces in memory, potentially allowing small structs to fit directly in interface values without pointers.

Upvotes: 1

Related Questions