Hiding nil values, understanding why golang fails here
The problem here is that shower
is an interface
type. Interface types in Go hold the actual value and its dynamic type. More details about this: The Laws of Reflection #The representation of an interface.
The slice you return contains 2 non-nil
values. The 2nd value is an interface value, a (value;type) pair holding a nil
pointer value and a *display
concrete type. Quoting from the Go Language Specification: Comparison operators:
Interface values are comparable. Two interface values are equal if they have identical dynamic types and equal dynamic values or if both have value
nil
.
So if you compare it to nil
, it will be false
. If you compare it to an interface value representing the pair (nil;*display)
, it will be true
:
if x == (*display)(nil) {
panic("everything ok, nil found")
}
This seems unfeasible as you'd have to know the actual type the interface holds. But note that you can use reflection to tell if a non-nil
interface value wraps a nil
value using Value.IsNil()
. You can see an example of this on the Go Playground.
Why is it implemented this way?
Interfaces unlike other concrete types (non-interfaces) can hold values of different concrete types (different static types). The runtime needs to know the dynamic or runtime-type of the value stored in a variable of interface type.
An interface
is just a method set, any type implements it if the same methods are part of the method set of the type. There are types which cannot be nil
, for example a struct
or a custom type with int
as its underlying type. In these cases you would not need to be able to store a nil
value of that specific type.
But any type also includes concrete types where nil
is a valid value (e.g. slices, maps, channels, all pointer types), so in order to store the value at runtime that satisfies the interface it is reasonable to support storing nil
inside the interface. But besides the nil
inside the interface we must store its dynamic type as the nil
value does not carry such information. The alternate option would be to use nil
as the interface value itself when the value to be stored in it is nil
, but this solution is insufficient as it would lose the dynamic type information.
Some people say that Go's interfaces are dynamically typed, but that is misleading. They are statically typed: a variable of interface type always has the same static type, and even though at run time the value stored in the interface variable may change type, that value will always satisfy the interface.
In general if you want to indicate nil
for a value of interface
type, use explicit nil
value and then you can test for nil
equality. The most common example is the built-in error
type which is an interface with one method. Whenever there is no error, you explicitly set or return the value nil
and not the value of some concrete (non-interface) type error variable (which would be really bad practice, see demonstration below).
In your example the confusion arises from the facts that:
- you want to have a value as an interface type (
shower
) - but the value you want to store in the slice is not of type
shower
but a concrete type
So when you put a *display
type into the shower
slice, an interface value will be created, which is a pair of (value;type) where value is nil
and type is *display
. The value inside the pair will be nil
, not the interface value itself. If you would put a nil
value into the slice, then the interface value itself would be nil
and a condition x == nil
would be true
.
Demonstration
See this example: Playground
type MyErr string
func (m MyErr) Error() string {
return "big fail"
}
func doSomething(i int) error {
switch i {
default:
return nil // This is the trivial true case
case 1:
var p *MyErr
return p // This will be false
case 2:
return (*MyErr)(nil) // Same as case 1
case 3:
var err error // Zero value is nil for the interface
return err // This will be true because err is already interface type
case 4:
var p *MyErr
return error(p) // This will be false because the interface points to a
// nil item but is not nil itself.
}
}
func main() {
for i := 0; i <= 4; i++ {
err := doSomething(i)
fmt.Println(i, err, err == nil)
}
}
Output:
0 <nil> true
1 <nil> false
2 <nil> false
3 <nil> true
4 <nil> false
In case 2 a nil
pointer is returned but first it is converted to an interface type (error
) so an interface value is created which holds a nil
value and the type *MyErr
, so the interface value is not nil
.
Let's think of an interface as a pointer.
Say you have a pointer a
and it's nil, pointing to nothing.
var a *int // nil
Then you have a pointer b
and it's pointing to a
.
var b **int
b = &a // not nil
See what happened? b
points to a pointer that points to nothing. So even if it's a nil pointer at the end of the chain, b
does point to something - it isn't nil.
If you'd peek at the process' memory, it might look like this:
address | name | value
1000000 | a | 0
2000000 | b | 1000000
See? a
is pointing to address 0 (which means it's nil
), and b
is pointing to the address of a
(1000000).
The same applies to interfaces (except that they look a bit different in memory).
Like a pointer, an interface pointing to a nil pointer would not be nil itself.
Here, see for yourself how this works with pointers and how it works with interfaces.