Why Does a Nil Slice Passed to an Interface in Go Not Equal Nil?

Understanding the nil Slice Paradox in Go Interfaces

When passing a nil slice as an interface, why is the result not nil? This puzzling behavior can be explained by understanding the underlying implementation of Go interfaces.

In Go, an interface{} variable is essentially a dual-field structure, comprised of a type descriptor and data value, as illustrated by the Iface struct:

struct Iface {
    Itab*   tab;
    void*   data;
};

Now, let's analyze the two function calls in the provided code:

<code class="go">yes([]int{}) // output: true
no([]int{})  // output: false</code>

yes Function:

In the yes function, the []int{} value is passed as the parameter thing. Since yes only accepts a slice parameter, the compiler treats nil as a zero-value slice. Thus, the comparison thing == nil becomes nil == nil, which returns true.

no Function:

In contrast, the no function expects an interface{} parameter. When you pass the []int{} value, Go automatically wraps it in an interface{} type. effectively converting it to interface{[]int, nil}. The comparison thing == nil now evaluates to interface{[]int, nil} == nil, which yields false.

This behavior is further clarified in the Go FAQ, which explains that "interfaces containing nil are only equal to nil if all of their members are nil" (i.e. in the case of this example, []int (the type member) cannot be nil).

Therefore, when dealing with nil slices in interfaces, it's crucial to be aware of this quirk and consider the underlying implementation to interpret the behavior correctly.

The above is the detailed content of Why Does a Nil Slice Passed to an Interface in Go Not Equal Nil?. For more information, please follow other related articles on the PHP Chinese website!