News for hackers. Stuff that matters.
Re:Down the Golang Nil Rabbit Hole by SPBS on Tuesday March 30, 2021 @01:05AM (#26631413)
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.
Re:Down the Golang Nil Rabbit Hole by tirrex on Tuesday March 30, 2021 @01:27AM (#26631489)
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.