Re:Nil in Go is typed in theory and sort of untyped in practice
by eptcyka on Wednesday March 31, 2021 @05:03PM
(#26653168)
I programmed in Go for three years, and got bitten by this at least twice.
Being able to determine if a value that implements an interface is nil or not would really be nice.
Re:Nil in Go is typed in theory and sort of untyped in practice
by jerf on Thursday April 01, 2021 @03:06PM
(#26664743)
That's actually not what this blog post was talking about. That's a separate issue. My commentary can be found https://news.ycombinator.com/item?id=26636227 , and see the grandchild as well.
Re:Nil in Go is typed in theory and sort of untyped in practice
by waheoo on Wednesday March 31, 2021 @05:45PM
(#26653547)
How does nil implement an interface?
Re:Nil in Go is typed in theory and sort of untyped in practice
by eptcyka on Wednesday March 31, 2021 @06:06PM
(#26653755)
A pointer to a type that implements an interface can be nil, but a function that takes said pointer as an interface type will not be able to distinguish between a pointer that points to an allocated object and a nil one.
Re:Nil in Go is typed in theory and sort of untyped in practice
by siebenmann on Wednesday March 31, 2021 @07:02PM
(#26654274)
Attempting to call a method on a nil interface value produces a runtime panic. Otherwise, it is the type that implements an interface, and it's possible that the type works even if the specific value of the type is nil. For instance, you could have a 'myIntPointer' type that is a pointer to an int, and implement a String() method for myIntPointer, and at that point a nil myIntPointer still has a String() method and implements the fmt.Stringer interface (although it may get a runtime panic if you actually call the method).
Re:Nil in Go is typed in theory and sort of untyped in practice
by autarch on Wednesday March 31, 2021 @02:22PM
(#26651001)
I agree that you won't think about this too often. However, if you're trying to use the reflect package to get type information about variables, you may end up having to think about it (and like me, you may end up feeling very confused!).
In general, you really haven't got much reason to be worried about something's "interface type", because if you're really worried about something's "type" (which can happen) you are almost certainly worried about it's "concrete type". The only interesting thing you can ask about the interface type directly would be "Does the value inside this interface implement this interface?", and the answer is statically yes, the compiler assured that, and the interface type is statically assured at runtime, so it's not a very interesting question. Even if fmt added a way to "see" the interface type passed in, I can't imagine what it would be useful for, because it could only ever be:
which would statically print "SomeInterfaceType".So, I mean, it's not like anything said in that blog post is false necessarily, but if you're collecting reasons to hate on Go's nil handling, there's no real justification in adding this to your list. I'd also add that I answer newbie questions a lot on Reddit, and nothing even remotely like this has ever come up there, either.