Why Does Go's Compiler Seem to Pass Pointers Implicitly When Calling Methods?

Understanding the Curious Behavior of Method Receivers in Go

In the realm of programming, the Tour of Go Exercise 51 presents an intriguing enigma. The Scale method, claimed to be ineffective when receiving a Vertex value rather than a pointer, defies this notion in practice.

To elucidate, the original code declares v, a variable of type Vertex, passed to Scale as &v. Surprisingly, replacing &v with v directly still produces an observable effect on the output.

Delving into the mechanics behind this phenomenon, we uncover that Go's strong typing system enforces the declaration of clear variable types. When a function or method requires a pointer to a certain type, such as T, only variables of that precise type (T) can fulfill this requirement.

However, Go's compiler possesses a concealed power: under specific conditions, it transforms the code for you. One such condition occurs when a non-pointer variable (x) is employed to invoke a method (m) that accepts a pointer receiver. Here, the compiler intervenes and effectively executes the statement (&x).m() instead of x.m(). This fascinating behavior aligns with Go's documentation, which states:

"A method call x.m() is valid if the method set of (the type of) x contains m and the argument list can be assigned to the parameter list of m. If x is addressable and &x's method set contains m, x.m() is shorthand for (&x).m():"

Understanding this concept clarifies the curious observation that Scale modifies the receiver even when provided with a non-pointer argument: the compiler's silent transformation ensures the intended behavior takes effect.

The above is the detailed content of Why Does Go's Compiler Seem to Pass Pointers Implicitly When Calling Methods?. For more information, please follow other related articles on the PHP Chinese website!