What two parts does a Go interface value hold, and when is it equal to nil?

### An interface value is a pair In Go, a variable whose type is an interface does not store a concrete value directly. It stores two things: 1. the **dynamic type** - which concrete type was last assigned to it (`*os.File`, `bytes.Buffer`, `int`, ...), and 2. the **value** of that type - the pointer, struct or number itself. Both halves come along together. The dynamic type is what lets the runtime find the right method to call when you write `w.Write(p)` without knowing which concrete type is inside. ### The zero value The zero value of every interface type is an interface with **both halves empty**. That is what people mean by a nil interface: ```go var w io.Writer // dynamic type: none, value: none fmt.Println(w == nil) // true ``` Calling a method on it has nowhere to dispatch, so it panics at runtime with `invalid memory address or nil pointer dereference`. This is the ordinary meaning of a nil check on an interface: has anything been put in here yet. ### Assignment fills the type half Assigning a concrete value writes both halves: ```go var buf bytes.Buffer var w io.Writer = &buf // type half: *bytes.Buffer, value half: address of buf ``` The crucial consequence is that the type half is filled in **whether or not the value half is meaningful**. A nil pointer is a perfectly good value of a pointer type: ```go var f *os.File // nil pointer var w io.Writer = f // type half: *os.File, value half: nil fmt.Println(w == nil) // false - one half is occupied ``` So `w == nil` is false. Nothing is broken here; the interface faithfully records that it is holding a `*os.File` that happens to be nil. This is the root of the typed-nil surprise people hit when a function returns a nil concrete pointer through an interface return type. ### Reading nil as a question about both halves The rule to memorise is one sentence: **an interface value is nil only when it holds no type and no value.** Every confusing case follows from it. Two useful corollaries: - Comparing an interface to `nil` never panics, no matter what is inside it. - `nil` on the right-hand side of the comparison is the untyped nil, which for an interface operand means the empty pair - not a nil pointer of some type. ### Seeing what is inside The cheapest diagnostic is the `%T` verb, which prints the dynamic type: ```go fmt.Printf("%T\n", w) // *os.File, or <nil> when the interface is empty ``` When a nil check is behaving unexpectedly, `%T` immediately separates the two situations: `<nil>` means the interface is truly empty, and any concrete type name means the type half is occupied and the interface cannot be nil. ### Methods still dispatch on a typed nil A subtle and useful point: if the interface holds a nil pointer, the method call still works - the runtime knows the type, so it knows which function to run. It is passed a nil receiver. Whether that panics depends entirely on the method body: ```go type Counter struct{ n int } func (c *Counter) Len() int { if c == nil { return 0 // nil-tolerant: no dereference } return c.n } ``` A method written like that behaves fine through an interface holding a nil `*Counter`. A method that dereferences the receiver panics. That is why the panic, when it comes, is a nil pointer dereference **inside the method**, not at the call site. ### Why Go was designed this way The alternative - collapsing an interface holding a nil pointer down to a nil interface - would throw away the type information, and with it the ability to call nil-tolerant methods, to distinguish which implementation was chosen, and to keep interface comparison well defined. Go pays for that with one famous trap and gains a model you can state in a single line: two halves, nil only when both are empty. ### What to say in an interview Name the pair, name the rule, then give the one-line demonstration with a nil pointer assigned to an interface variable and the resulting `false` from the nil comparison. Reaching for `%T` as the diagnostic shows you have debugged it rather than only read about it.