Nil pointer to struct not deep equal to nil? - pointers

If I have a struct containing a nil pointer of type A, using reflect.DeepEqual to check if that property is nil will result in false, which strikes me as odd behaviour.
type Container struct {
O *Obj
}
type Obj struct {
Message string
}
var c Container
eq := reflect.DeepEqual(c.O, nil)
fmt.Printf("O value: %v, is nil: %t", c.O, eq)
// Prints: "O value: <nil>, is nil: false"
Specifically, I am marshaling a JSON object into a struct, where I would like to test that a specific property is nil when the corresponding JSON structure does not contain it. If reflect.DeepEqual is not the way to go, how should I do this?

Everything you pass to reflect.DeepEqual() is wrapped in an interface{} value (if it's not already that):
func DeepEqual(x, y interface{}) bool
interface{} values will be compared, where the first parameter value is not nil, only the value wrapped in it.
An interface value is represented as a (type; value) pair. The first value you pass to reflect.DeepEqual() is a pair of (type; value) being (*Obj, nil), and the 2nd value is nil. They are not equal. The second value lacks type information.
If you compare it to a "typed" nil, it will be true:
reflect.DeepEqual(c.O, (*Obj)(nil)) // This is true
See this example:
fmt.Println("c.O:", c.O)
fmt.Println("c.O == nil:", c.O == nil)
fmt.Println("c.O deep equal to nil:", reflect.DeepEqual(c.O, nil))
fmt.Println("c.O deep equal to (*Obj)(nil):", reflect.DeepEqual(c.O, (*Obj)(nil)))
Output (try it on the Go Playground):
c.O: <nil>
c.O == nil: true
c.O deep equal to nil: false
c.O deep equal to (*Obj)(nil): true
See this question for a deeper insight:
Hiding nil values, understanding why golang fails here
If you want to check if the value wrapped inside a non-nil interface is nil, you can use reflection: reflect.Value.IsNil().
For more details see: Why interface type doesn't provide an "IsNil" method?

Related

What's special about an empty list returned from a map[string][]string

Here's a weird situation where I don't understand what Go is doing. I ended with some code that used the default value of map that hasn't had that key inserted into it yet.
package main
import (
"fmt"
"reflect"
)
func main() {
mmm := map[string][]string{}
nnn := map[string][]string {
"a": {},
}
x := mmm["a"]
y := nnn["a"]
z := []string{}
fmt.Println(reflect.DeepEqual(x,y))
fmt.Println(reflect.DeepEqual(x,z))
fmt.Println(reflect.DeepEqual(y,z))
fmt.Printf("%T, %T, %T", x, y, z)
}
I get the unexpected output
false
false
true
[]string, []string, []string
where I would expect true across the board. What is it about the default value of a map that does this?
If you add another printing line:
fmt.Printf("%#v, %#v, %#v", x, y, z)
It'll all become clear. It outputs (try it on the Go Playground):
[]string(nil), []string{}, []string{}
x is a slice being nil, and y is a non-nil slice having 0 length, just like z.
Indexing a map with a key that's not in the map, it results in the zero value for the value type of the map. In your case the value type is []string, its a slice type, and zero value for slice types is nil.
And reflect.DeepEqual() documents that a nil slice and a non-nilslice are not equal:
Note that a non-nil empty slice and a nil slice (for example, []byte{} and []byte(nil)) are not deeply equal.
First, just a quick correction, this kind of data type is called a "slice", not a "list".
When you look-up a map key that doesn't exist, you get the "zero value" of the map's value type. In the case of slices, the zero-value is a nil slice. A nil slice generally behaves much like an empty slice (for example, the len of a nil slice is zero), but they are not considered to be the same. Equality is not actually defined for slices in Go, so it is up to reflect.DeepEqual to decide what equality means here.
You'll see this note in the documentation explaining the behaviour here:
Slice values are deeply equal when all of the following are true: they are both nil or both non-nil, they have the same length, and either they point to the same initial entry of the same underlying array (that is, &x[0] == &y[0]) or their corresponding elements (up to length) are deeply equal. Note that a non-nil empty slice and a nil slice (for example, []byte{} and []byte(nil)) are not deeply equal.

Why does printing of a (nil) map in golang yield a non "<nil>" result?

In golang, if you create a struct with a map in it, which is uninitialized, printing the map yields a non <nil> string.
Why does "print" of a nil map output "map[]" instead of <nil> ?
// Assume above there is a struct, a.AA, which is created but which otherwise
// has not created the map.
//output:
//map[]
//map[]
fmt.Println(a.AA)
fmt.Println(make(map[string]int64))
It's just for making things clear. If you run this code:
var m map[string]int64
log.Println(m == nil)
log.Printf("%T\n", m)
It will print:
$ true
$ map[string]int64
So m is actually nil at this point. A nil value (can) have a type too and the formater uses that to print out something meaningful when possible.
A map behaves like a reference type in other languages. And in Go you can call methods of a struct even if its value is nil.
So even for your own structs, you can implement fmt.Stringer interface by just defining the String() string method on your struct and whenever your struct's value is nil you can print out something more proper than <nil>. Having:
type someData struct {
someValue string
}
func (x *someData) String() string {
if x == nil {
return "NO PROPER DATA HERE!"
}
return x.someValue
}
Then if we run:
var data *someData
log.Println(data)
data = new(someData)
data.someValue = "Aloha! :)"
log.Println(data)
The output will be:
$ NO PROPER DATA HERE!
$ Aloha! :)
See at the first line we did not get <nil> as output, despite the fact that our struct pointer is nil at that point.
A nil pointer is not the same as an empty (or zero) map. See https://golang.org/ref/spec#The_zero_value for authoritative information concerning zero values.
If you want a nil, you need a pointer, such as in the following example:
package main
import (
"fmt"
)
func main() {
var myMap map[string]int64
fmt.Printf("myMap before assignment: %v\n", myMap)
myMap = make(map[string]int64)
fmt.Printf("myMap after assignment : %v\n", myMap)
var myMapPointer *map[string]int64
fmt.Printf("myMapPointer before assignment: %v\n", myMapPointer)
myMapPointer = new(map[string]int64)
fmt.Printf("myMapPointer after assignment : %v\n", myMapPointer)
}
This gives:
myMap before assignment: map[]
myMap after assignment : map[]
myMapPointer before assignment: <nil>
myMapPointer after assignment : &map[]

Null vs nil in golang?

I ran into a strange bug today. I had a function:
func Foo(s *someStruct) {
fmt.Printf("s is %v\n", s)
if s!=nil {
fmt.Printf("s is not nil")
...
}
}
I would call the function like:
var s *someStruct
Foo(s)
And then I decided to convert the structure into interface:
func Foo(s someStructInterface) {
fmt.Printf("s is %v\n", s)
if s!=nil {
fmt.Printf("s is not nil")
...
}
}
Which gave me a strange output:
s is null
s is not nil
While I expected to get s is nil, which is what I was getting usually. What is the difference between null and nil in this scenario in Go and how can I check if something is null or nil to execute the code properly?
An interface value contains a reference to a type and a value. In the following code:
var s *someStruct
Foo(s)
the interface value passed to Foo contains a reference to the type *someStruct and a nil.
The statement fmt.Printf("s is %v\n", s) outputs s is <nil> because of the following:
The %v format prints a value using the default format for the type. The value s contains a pointer type. The default format for a pointer type is %p. The %p format prints nil pointers as <nil>.
The expression s != nil evaluates to true because an interface value is equal to nil if and only if the type reference is nil. In this case, the interface value references the type *someStruct.

Golang, convert nil pointer of struct to error, but not get nil value [duplicate]

I fail to understand how to correctly assure that something is not nil in this case:
package main
type shower interface {
getWater() []shower
}
type display struct {
SubDisplay *display
}
func (d display) getWater() []shower {
return []shower{display{}, d.SubDisplay}
}
func main() {
// SubDisplay will be initialized with null
s := display{}
// water := []shower{nil}
water := s.getWater()
for _, x := range water {
if x == nil {
panic("everything ok, nil found")
}
// First iteration display{} is not nil and will
// therefore work, on the second iteration
// x is nil, and getWater panics.
x.getWater()
}
}
The only way I found to check if that value is actually nil is by using reflection.
Is this really wanted behaviour? Or do I fail to see some major mistake in my code?
Play link 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 // == nil
case 1:
var p *MyErr
return p // != nil
case 2:
return (*MyErr)(nil) // != nil
case 3:
var p *MyErr
return error(p) // != nil because the interface points to a
// nil item but is not nil itself.
case 4:
var err error // == nil: zero value is nil for the interface
return err // This will be true because err is already interface type
}
}
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> false
4 <nil> true
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.
I'll take an alternative route to answer your concrete question, by providing the exact answer you were looking for:
Replace the check:
if x == nil {
panic("everything is ok. nil found")
}
with:
if _, ok := x.(display); !ok {
panic("everything is ok. nil found")
}
The idea here is that we are trying to convert the interface type (shower) to the concrete type display. Obviously the second slice item (d.SubDisplay) is not.

Set an interface to nil in Golang

I'm trying to set an internal value of an interface to nil something like the following :
typ := &TYP{InternalState: "filled"}
setNil(typ)
fmt.Printf("Expecting that %v to be nil", typ)
And I need to know how to implement the setNil(typ interface{}) method.
For more details see this code in play.golang.org.
The thing is you don't have an interface value. You have a pointer value, a pointer to a concrete type. That is not the same as an interface value.
If you want to change the value of a variable of any type, you have to pass a pointer to it. This also includes variables of interface type, and also variables of pointer type. This is one of those very rare cases when a pointer to interface{} makes sense (*interface{}), in fact it's inevitable.
But if your function expects an interface and you pass a non-interface value, an interface value will be created implicitly and you could only nil this implicitly created value.
So we have 2 different / distinct cases:
Function to nil an interface{}
func setNilIf(v *interface{}) {
*v = nil
}
Using it:
var i interface{} = "Bob"
fmt.Printf("Before: %v\n", i)
setNilIf(&i)
fmt.Printf("After: %v\n", i)
Output:
Before: Bob
After: <nil>
So it works.
Function to nil a pointer; using unsafe
Actually this is your case. We want to change the value of a variable of pointer type. To accept a pointer to any type, we can use unsafe.Pointer. unsafe.Pointer is a language support, it's a special pointer type which can be converted from and to any pointer type.
We want to accept the address (pointer) of the pointer variable, which is something like **SomeType. To actually be able to assign a new value (nil) to the pointer variable, we have to dereference it (* operator). But unsafe.Pointer cannot be dereferenced, so first we have to convert it to a pointer to pointer to "something", but since we only want to assign nil (which is the same to all pointer types regardless of the type of the pointed value), the "something" doesn't matter, I will just use int, and so I will convert the unsafe.Pointer pointer value to **int.
func setNilPtr(p unsafe.Pointer) {
*(**int)(p) = nil
}
Using it:
typ := &TYP{InternalState: "filled"}
fmt.Printf("Before: %v\n", typ)
setNilPtr(unsafe.Pointer(&typ))
fmt.Printf("After: %v\n", typ)
Output:
Before: &{filled}
After: <nil>
So this one also works. There is still another way using reflection:
Function to nil a pointer; using reflect
You can also nil a pointer using reflection only (reflect package). We still have to pass the address of the variable of pointer type. Note that in this case the type of the parameter will simply be interface{}. And it will contain a dynamic type like **SomeType. Since pointers have zero value nil, we can obtain such a value with reflect.Zero() which we will set using Value.Set():
func setNilPtr2(i interface{}) {
v := reflect.ValueOf(i)
v.Elem().Set(reflect.Zero(v.Elem().Type()))
}
Using it:
typ2 := &TYP{InternalState: "filled"}
fmt.Printf("Before: %v\n", typ2)
setNilPtr2(&typ2)
fmt.Printf("After: %v\n", typ2)
Output:
Before: &{filled}
After: <nil>
So this one also works. Try these on the Go Playground.
But seriously: if you want to nil something, assign nil to it. Do not complicate things unnecessarily.
i = nil
typ = nil

Resources