If resp is a pointer to a response object, why don't we have to use resp* to access its value? - pointers

Question

I recently began studying Golang and the accompanying documentation. In the Golang net/http documentation , the Get method is:
func Get(url string) (resp *Response, err error)
It is my understanding that this method returns a pointer to a response object or an error object (should an error occur). If resp is a pointer to a response object, why can the respvalue be accessed using the following code:
func main() {
resp, err := http.Get("http://google.com")
if err != nil {
fmt.Println("Error:", err)
os.Exit(1)
}
fmt.Println(resp)
}
Should it not be fmt.Println(*resp) instead? There are many other examples like this throughout the documentation. I thought I understood pointers but I am obviously missing something. Any help in clarifying this would certainly be appreciated.

Answer 1

If resp is a pointer to a response object, why can the [object itself] be accessed using [fmt.Println(resp)] ... Should it not be fmt.Println(*resp) instead?
If you send to fmt.Println a pointer to an object, fmt.Println can use the pointer to reach the object itself (i.e., access it—and even modify it, but fmt.Println doesn't modify it).
If you send to fmt.Println a copy of the object, fmt.Println can use the copy of the object, i.e., access it (and cannot modify the original).
So in that sense, giving fmt.Println the pointer value is strictly more powerful than passing a copy of the object, because it can modify the object. The fmt code does not use this power, but it's there in any other place that you might pass the pointer too. But as long as fmt.Println:
notices that this is a pointer, and then
follows the pointer to access the underlying object,
then fmt.Println can behave the same way on both pointer-to-object and copy-of-object.
In fact, the fmt.Print* family of functions do not quite behave the same way with pointer-to-object and copy-of-object:
package main
import (
"fmt"
)
type T struct {
Name string
Value int
}
func main() {
obj := T{Name: "bob", Value: 42}
fmt.Println(&obj, obj)
fmt.Printf("%#v %#v\n", &obj, obj)
}
When this is run (try it on the Go Playground), it prints:
&{bob 42} {bob 42}
&main.T{Name:"bob", Value:42} main.T{Name:"bob", Value:42}
That is, the default formatting, which you get with %v or fmt.Println, prints either:
{bob 42}
(copy of object) or:
&{bob 42}
(pointer to object). The alternative format obtained with %#v adds the type, so that you either get:
main.T{Name:"bob", Value:42}
(copy of object) or:
&main.T{Name:"bob", Value:42}
What we see here is that fmt.Println, which takes an interface{} value, goes through the following process:
Inspect the type of the value. Is it a pointer? If so, remember that it was a pointer. Print <nil> and do not go any further if it's a nil pointer; otherwise, obtain the object to which the pointer points.
Now that it's not a pointer: What type does the value have? If it's a struct type, print out its type name (%#v) or not (%v), prefixed with & if step 1 followed a pointer, and then the open brace and a list of the values of things inside the struct, and then a close brace to end the whole thing.
When using %#v, print the names of the fields and print the values in a format suitable for use as Go source code. Otherwise, just print the contents of strings and ints and so on.
Other pointer types do not always get the same treatment! For instance, add a int variable, set it to some value, and call fmt.Println(&i, i). Note that this time you don't get &42 42 or something like that, but rather 0x40e050 42 or something like that. Try this with fmt.Printf and %#v. So the output depends on the type and the formatting verb.
If you call functions that must modify their objects (such as the scan family in fmt), you must pass a pointer, since they need to have access to the objects to modify them.
Every function that can take values of unconstrained interface{} types (including everything in the Print* and Scan* family here) must document what they do with each actual type. If they say, as the Print* family do, that when given a pointer to a struct type, they follow the pointer (if not nil), that lets you know that you can send the pointer instead of the object.
(Some functions in some libraries are guilty of under-documenting what they do, and you have to experiment. This is not a great situation in general because the results of the experiment might be an accident of the current implementation, rather than a promised behavior that won't change in the future. This is one reason to be chary of using interface{}: it means you have to write a lot of documentation.)