Right, so you’ve got a pointer receiver. You’ve got a variable that’s nil. You call a method on it. Your gut says this should be a one-way ticket to panicville, right? Well, put that gut on hold, because Go is about to show you one of its more interesting, and frankly, brilliantly pragmatic, party tricks.

In most languages, calling a method on a nil reference is the runtime equivalent of jumping off a cliff while yelling “I regret nothing!” It’s an immediate segfault or a null pointer exception. Go, however, in its relentless pursuit of being useful rather than pedantic, says, “Hold my beer.” It is perfectly valid to call a method on a nil pointer receiver. The method will execute. Now, whether that’s a good idea or not depends entirely on what you wrote inside that method.

Why This Doesn’t Immediately Panic

The reason this works is syntactic sugar. Under the hood, a method call like myNilPointer.MyMethod() is translated into a function call: MyMethod(myNilPointer). The receiver is just a function parameter. And in Go, you are absolutely allowed to pass a nil pointer to a function. The panic doesn’t happen when you call the method; it happens later, inside the method, if you try to dereference that nil pointer to access a field.

Think of it this way: the method is just a set of instructions. You’ve handed those instructions a piece of paper that says “no object here.” If the instructions say “take the object and change its Name field,” you’re going to have a bad time. But if the instructions say “if the object is nil, print a warning and return,” then you’re golden. This is the entire foundation of making nil useful.

A Tale of Two Methods

Let’s look at this in action. Here’s a classic example of what not to do.

type Wallet struct {
    balance int
}

func (w *Wallet) Deposit(amount int) {
    w.balance += amount // Kaboom! (if w is nil)
}

func main() {
    var emptyWallet *Wallet = nil // It's just a pointer, pointing at nothing.
    emptyWallet.Deposit(100)      // This line is valid Go code.
}

Run that, and you’ll get the panic you initially expected: panic: runtime error: invalid memory address or nil pointer dereference. The Deposit method blindly tries to dereference w to get to balance, and that’s the illegal operation.

Now, let’s write a smarter method.

func (w *Wallet) Balance() int {
    if w == nil {
        fmt.Println("Warning: called Balance() on a nil Wallet. Returning 0.")
        return 0
    }
    return w.balance
}

func main() {
    var emptyWallet *Wallet = nil
    balance := emptyWallet.Balance() // This works perfectly fine.
    fmt.Println("Balance:", balance)  // Prints: Warning... \n Balance: 0
}

No panic. The method handles the nil case gracefully. This is a perfectly legitimate pattern. It turns a potentially catastrophic runtime error into a predictable, manageable outcome.

The Zero Value Principle and Meaningful nil

This feature isn’t a weird loophole; it’s a core part of the language’s design philosophy around zero values. A nil pointer isn’t necessarily an “error” state. It can be a meaningful, useful value. Consider a TreeNode in a tree structure:

type TreeNode struct {
    Val   int
    Left  *TreeNode
    Right *TreeNode
}

// A method on a nil TreeNode can be the base case for recursion.
func (t *TreeNode) Sum() int {
    if t == nil {
        return 0 // A non-existent node has a sum of 0. This makes perfect sense.
    }
    return t.Val + t.Left.Sum() + t.Right.Sum() // This works because Left/Right can be nil.
}

func main() {
    // A tree with just a root node and a left leaf.
    root := &TreeNode{
        Val: 10,
        Left: &TreeNode{Val: 5},
        Right: nil, // Right subtree is just nil, not a TreeNode{}. 
    }

    sum := root.Sum() // 10 + 5 + 0 = 15
    fmt.Println(sum)
}

Here, nil represents the concept of “no child.” The Sum() method elegantly uses the zero value for an integer (0) to define the behavior of a nil node. This is idiomatic, clean, and avoids having to create dummy “empty” structs everywhere.

The Pitfall: When Your nil Isn’t Their nil

Here’s the gotcha. This only works for method calls where the receiver is literally a nil pointer of the defined type. If your method has a value receiver, the whole discussion is moot because you can’t even have a value receiver on a nil pointer—the value would be copied, and if it’s a nil pointer inside a struct, you’re back to the same problem.

The more subtle pitfall is interface wrappers. This is where the real runtime panics live.

type Depositer interface {
    Deposit(int)
}

func main() {
    var concrete *Wallet = nil // This is a nil Wallet pointer.
    var interfaced Depositer = concrete // This is NOT nil.

    fmt.Println(concrete == nil) // true
    fmt.Println(interfaced == nil) // false (!)

    // This will panic, and the panic message will be utterly confusing.
    interfaced.Deposit(100) 
}

Wait, what? interfaced is not nil? Correct. An interface value is nil only if both its type and value components are nil. When you assign concrete (a nil pointer of type *Wallet) to interfaced, the interface’s internal type component is now set to *Wallet, and its value component is nil. This is a non-nil interface value. When you call Deposit through the interface, it blindly dispatches to the *Wallet method, passing in the nil value, and the method then panics. This is a very common source of bugs.

The rule of thumb: If a method might be called on a nil receiver, you must check for nil inside the method. There is no way around it. Relying on callers to never pass nil is a recipe for a crash. Embrace the check. It’s not a code smell; it’s a necessary guard clause that enables this powerful, useful feature.