Why assign a reference to a struct in go?

Question

I'm having a look at the code at this page:

http://golang.org/pkg/net/http/

And there's one thing I don't understand - at some point, a new structure is created and initialized like this:

client := &http.Client{
    CheckRedirect: redirectPolicyFunc,
}

Why use & when creating this structure?

I've also read this blog post and structs are initialized like this:

r := Rectangle{}

What is the difference between both and how should I know which one to use?

Emelinaemeline

the word reference is confusing in regard to its usage within the spec. golang.org/ref/spec#Package_initialization A reference to a variable or function is an identifier denoting that variable or function.. Go does have a concept of pointers, although. – Conciliatory

Answer 1

The difference is in the type of your variable.

client := &http.Client{

makes client of type *http.Client

while

client := http.Client{

builds a http.Client.

Inconsistent

I understand the difference between pointers and values but in this particular example, why did they create a pointer? Why not call client := http.Client? Are there benefit from building it using client := &http.Client? – Emelinaemeline

A pointer is light. When you don't have a pointer, you copy the structure each time you assign it to a variable. Which means you might do operations on copies of your structure instead of your original structure and which might be heavy. You should use a pointer for most complex structure. See also this related question. – Tautonym

Answer 2

The top one is returning a pointer. It is a Go idiom instead of using new. The second one is just a value object. If you need a pointer use the top.

Check the effective go doc for more about this

http://golang.org/doc/effective_go.html#allocation_new

Gil

Answer 3

In object-oriented programming, in order for an object to have dynamic lifetime (i.e. not tied to the current function call), it needs to be dynamically allocated in a place other than the current stack frame, thus you manipulate the object through a pointer. This is such a common pattern that in many object-oriented languages, including Java, Python, Ruby, Objective-C, Smalltalk, JavaScript, and others, you can only deal with pointers to objects, never with an "object as a value" itself. (Some languages though, like C++, do allow you to have "objects as values"; it comes with the RAII idiom which adds some complexity.)

Go is not an object-oriented language, but its ability to define custom types and define methods that operates on that custom type, can be made to work very much like classes and methods. Returning a pointer to the type from the "constructor" function allows the "object" to have a dynamic lifetime.

Wino

Answer 4

When we use reference, we use a single item throughout the program runtime. Even if we assign that to a new variable or pass through a function. But when we use value, we make new copies of individual items.

( Reference is not right word according to golang convention. "Address of value" would be more appropriate here https://golang.org/ref/spec#Package_initialization )

An example will make it much clear I hope.

type Employee struct {
    ID      int
    Name    string
    Address string
}

func main() {

    andy := &Employee{}

    andy.Name = "Andy"

    brad := andy

    brad.Name = "Brad"

    fmt.Println(andy.Name)
}

The result of this code block would be:

Brad

As we made new variable from it but still referring to same data. But if we use value instead of reference and keep the rest of the code same.

// from 
andy := &Employee{}
// to
andy := Employee{}

This time the result would be:

Andy

As this time they both are individual items and not referring to same data anymore.

Archaimbaud

the word reference is confusing in regard to its usage within the spec. golang.org/ref/spec#Package_initialization A reference to a variable or function is an identifier denoting that variable or function.. Go does have a concept of pointers, although. – Conciliatory

You are right. Thanks for pointing out. I'll update accordingly. Though current one would make sense to people understands c/c++, but it's not correct according to Go. – Archaimbaud