Wait, am I misunderstanding, or are you saying the code would usually be written as:
func (c *GZipComprosser) compress() []byte {
if (c == nil) {
return []byte{}
}
return []byte{c.internal}
}
I don't think that's common at all (1) nor is it a sane burden to put on developers.
(1) https://github.com/golang/go/blob/master/src/bytes/buffer.go...
It depends on the context. My guess as to why bytes.Buffer doesn't perform the nil check is to not shield developers away from the fact that they can't do very much with a nil pointer Buffer: there's no backing allocation and the code should panic early to flag it out. But if you decide that a nil pointer receiver is a valid state for the receiver to be in (especially if it is going to be a struct field in which case the zero value is always nil), you should do the nil check. That's just life with Go, remember you are talking about a language that sprinkles `if err == nil` everywhere. Checking for nil pointer receiver (in every method) is just par for the course.
If you add nil checks to each receiver method, potentially, you are adding thousands of unnecessary branches to your program. It would be quite inefficient. You will ruin performance & readability altogether.
Better way is what you described, accept nil state as invalid, require user to handle it (user must initialize before using your method)
Re:Down the Golang Nil Rabbit Hole
by tedunangst on Tuesday March 30, 2021 @01:26AM
(#26631481)
> Checking for nil pointer receiver (in every method) is just par for the course.
Or not.
Re:Down the Golang Nil Rabbit Hole
by andrewstuart2 on Tuesday March 30, 2021 @02:12PM
(#26638152)
It's pretty common. Common enough that it's built into the go tour: https://tour.golang.org/methods/12
Yeah, I've never seen this before. However, I _did_ learn that the receiver can be a nil pointer, which I've never thought of. It seems to me that this should fail spectacularly anyway, and shouldn't need to be handled there...
Got bitten by this too in my early days of learning go. This was around v1.4 and until now haven't seen or had the need to pass a SomeInterface(nil) to any function or method call. To me it's more a consequence of the type system design (in most languages you can't call a method on a nil/null object) than a feature
https://play.golang.org/p/FUS2-CcHflX
The more I played with the code, the more I have to agree with the commenter. This is not obvious behavior.
You can also get into obscure behavior if your implementation does not have a pointer receiver. Take this code for example: https://play.golang.org/p/MjjGMAZL3-v How can I get a nil pointer immediately after I checked whether it was nil? This one, I do know has bitten me before. Infrequently, but it has.