Lets say you have a nil pointer and you assign it to an interface:
var p *T = nil
intfc interface{} = p
I expected intfc to now be nil, but it's not.
The explanation (it's even in the FAQ) is in terms of the implementation. An interface contains a pointer and a type. When we assign a nil pointer the interface type is set. And an interface is only nil if both the pointer and the type are "empty".
I understand the explanation and it's not hard to work around once you're aware of it. If you want to return an interface that compares equal to nil you just have to make sure you don't assign a nil pointer to it.
But I don't find the explanation very satisfying.
First, justifying some external behavior by explaining how you happened to implement it seems wrong. (Although to be fair, maybe the explanation is intended to be in terms of what an interface means, not really how it's implemented.)
Second, the explanation doesn't explain why they chose to make it work this way. Granted, it's simple because the nil check is just for a zeroed value. But it doesn't seem like it would be much harder for the compiler to just check for a zeroed pointer and ignore the type. It seems like this would avoid the unexpected behavior with no real loss of functionality.
I did some searching, but the only justification I could find is that a nil pointer in an interface can still satisfy the interface and you can still call methods on it. Which is fine, but what does that have to do with whether the interface value compares equal to nil? I guess it would introduce a new oddity in that you'd have two kinds of nil interfaces only one of which you could call methods on.
The other issue is that (afaik) you can't determine if an interface holds a nil pointer without using reflection.
It's not a big deal, and I'm not hung up on it, it just seems odd. As far as languages are concerned, I would say Go has relatively few sharp corners to get caught on.
1 comment:
You can't know if an interface contains a nil pointer without knowing the type of that nil pointer.
This is important because the meaning of that nil pointer is only defined within it's type. A nil []byte is perfectly useful.
If a nil interface value was equal to an the value of an interface containing a nil pointer then there would be no way to distinguish between an interface containing a nil pointer and one that has no type or value.
Similarly, an interface can contain values that can't be nil, like an int.
What should be the semantics of this?
interface{}(5) == nil
Post a Comment