Why Does Go Implicitly Dereference When Calling Pointer Receiver Methods?

Go Method Sets: Invoking Methods for Pointer Types and the Receiver

One often-discussed aspect of Go method sets arises when attempting to call methods with receiver type T on variables of type T. The Go specification states that the method set of T includes both the methods with receiver type *T and those with receiver type T.

Conflicting Inferences

However, the following example demonstrates that this inference can seem counterintuitive:

package main

import (
    "fmt"
    "reflect"
)

type User struct{}

func (self *User) SayWat() {
    fmt.Println(self)
    fmt.Println(reflect.TypeOf(self))
    fmt.Println("WAT\n")
}

func main() {
    var user User = User{}

    fmt.Println(reflect.TypeOf(user), "\n")

    user.SayWat()
}

Compiler Inference

The compiler infers that user.SayWat() calls the method with receiver type *T, although the variable user has type T. This behavior is caused by the compiler's automatic insertion of &, the address-of operator. In essence, it rewrites the call to (&user).SayWat().

Calling Methods for Pointer Types

It's important to clarify that while it appears that methods for pointer types are called on variables of type T, this is not strictly true. The compiler uses a receiver of type *T, and the dereferencing of &user to T is an implicit operation.

Exceptions to Implicit Dereferencing

However, this implicit dereferencing does not apply in all cases. Calling a method with a pointer receiver on a return value (non-addressable) will result in a compile-time error, such as:

func aUser() User {
    return User{}
}

...

aUser().SayWat()

Error Message

cannot call pointer method on aUser()
cannot take the address of aUser()

The above is the detailed content of Why Does Go Implicitly Dereference When Calling Pointer Receiver Methods?. For more information, please follow other related articles on the PHP Chinese website!