3 ms·
For some context, I've been programming in Go for about six years now, and I've literally never even thought about this. In general, you really haven't got muc
by jerf 6y ago
For some context, I've been programming in Go for about six years now, and I've literally never even thought about this.
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:
var x SomeInterfaceType
// some number of lines of code
fmt.Printf("%I\n", x)
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.
- autarch 6y agoI 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!).
- deleted 6y ago[deleted]
- eptcyka 6y agoI 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.
- waheoo 6y agoHow does nil implement an interface?
- eptcyka 6y agoA 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.
- siebenmann 6y agoAttempting 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).
- jerf 6y agoThat'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 https://news.ycombinator.com/item?id=26636227 , and see the grandchild as well.