By sharpner


2015-03-19 06:42:12 8 Comments

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

2 comments

@icza 2015-03-19 06:47:48

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 value and a *display 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.

@sharpner 2015-03-19 06:52:11

that's a pretty... big fail isn't it? How can I write a library that provides interfaces that way? I could assure that it works correctly if the users provides correct types with nil value. I guess if x == (shower)(nil) would make sense but that is just shocking..

@Volker 2015-03-19 07:06:06

There is nothing shocking about it. Your return a slice of two interface values, both are non-nil. One of those non-nil interface values contains a nil value. The interface value has to be non-nil to contain anything, even a nil. You can either fix it like icza suggested, or redesign your API, e.g. not returning a slice of interfaces.

@icza 2015-03-19 07:11:27

@sharpner You can provide a library which uses/returns values of interface types. But if the value is "missing", return nil explicitly.

@sharpner 2015-03-19 07:42:35

I'm still trying to wrap my head around how to redesign the api. Maybe a typedef something []shower will get me further or I don't know yet. But I really learned something quite new about go today. My example simplifies the real problem somewhat. In the final implementation, the user of my library has to implement getWater() and therefore can make mistakes. So, since I got to assume that this will happen, I needed to assure that no nil values are in the slice. I anticipated that users can return pointer to structs or structs that implemented the interface....

@Nate Finch 2015-03-19 17:59:38

A nil pointer is not an invalid value. Note that you can call methods on nil pointers just fine: play.golang.org/p/Agd8eIwaKZ Try reading my post about nil pointer and nil interfaces, it may help: npf.io/2014/05/intro-to-go-interfaces/#toc_4

@sharpner 2015-05-07 11:13:15

wow that's interesting. Thanks @NateFinch

@Target-san 2015-11-10 09:56:22

@icza I understand that this topic is a bit old. But I can't really understand why this is allowed as implicit coercion. Wouldn't it be more understandable to produce fully nil interface pointer from nil structure pointer? Or to check only value pointer against nil? Pike et al were saying so much about removing all unobvious and controversial things. And yet they leave this pretty much bug. Because it effectively allows to produce reference with broken invariants. Calling methods over nil pointers is such a rare case, and more like a hack, that I don't consider it as a valid explanation.

@AndrewN 2015-11-11 00:54:32

@Target-san In that case a coder could no long check an interface variable against nil to verify that it was truly completely nil, that it held no dynamic type information, and you'd simply move this entire class of tricky behavior in a slightly different problem space. IOW, there's no simple/obvious answer here, because sometimes you might want to know if the value is nil and sometimes you might want to know if both type/value are nil.

@Target-san 2015-11-12 09:42:55

@AndrewN Thanks for explanation. Though I found the answer on go-nuts group. Brief: Go uses pointers, and not references. For reference, nil is like NaN for floats. But for pointer nil is just yet another value. The difference seems to be semantical, because references and pointers usually have same representation under the hood.

@AndrewN 2015-11-12 16:12:23

Yeah I read that thread, it was quite educational. :)

@Moshe Revah 2015-12-17 20:09:51

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.

Related Questions

Sponsored Content

2 Answered Questions

[SOLVED] Value receiver vs. pointer receiver

  • 2015-01-05 07:54:11
  • Chrisport
  • 16868 View
  • 82 Score
  • 2 Answer
  • Tags:   function pointers go

1 Answered Questions

[SOLVED] pointer receiver vs value receiver

1 Answered Questions

0 Answered Questions

Golang check if interface is nil

  • 2017-11-20 17:28:53
  • fabstab
  • 1175 View
  • 0 Score
  • 0 Answer
  • Tags:   go

1 Answered Questions

[SOLVED] Golang set nil string pointer value in struct using reflect

1 Answered Questions

[SOLVED] Convert nil interface to pointer of something in Golang?

  • 2015-05-11 07:51:36
  • Mihnea Giurgea
  • 16373 View
  • 13 Score
  • 1 Answer
  • Tags:   pointers interface go

3 Answered Questions

[SOLVED] Why is malloc returning NULL here?

3 Answered Questions

[SOLVED] How to get underlying value from a reflect.Value in golang?

  • 2013-08-06 22:23:29
  • lucidquiet
  • 26150 View
  • 30 Score
  • 3 Answer
  • Tags:   reflection go

2 Answered Questions

[SOLVED] Why `Nil` is defined as `case object`

  • 2014-06-30 15:46:09
  • Freewind
  • 308 View
  • 7 Score
  • 2 Answer
  • Tags:   list scala case null

2 Answered Questions

[SOLVED] Structs cannot be nil, but this is compiling

  • 2014-06-28 09:37:05
  • Mariy
  • 10903 View
  • 2 Score
  • 2 Answer
  • Tags:   go

Sponsored Content