3 ms·

I know why it crashes (now, I hit this bug almost 6 years ago), the problem is it isn't intuitive or idiomatic. 1. Checking for nil receivers is rare and hardl

I know why it crashes (now, I hit this bug almost 6 years ago), the problem is it isn't intuitive or idiomatic. 1. Checking for nil receivers is rare and hardly idiomatic. (Although I have seen methods that are designed to work with nil receivers) 2. (*T)nil != nil is surprising. A newbie looking at this code would not expect it to crash which is why I consider it a wart. In this specific case, the code was structured such that if the compressor was nil then no compression would happen. Then in some, hard to remember case, when you opted into gzip the whole thing would crash. I think I had been writing Go for about 18 months at that point and that snippet got past review. Ultimately the design had problems, (depending on `nil` to mean anything was probably dangerous and it's clearer to give NoCompression it's own type) so I'm not really arguing that the above snippet should work. Once you understand why it's there it makes sense, but ultimately I think it's an unfortunate side effect of designing a language with nullable types.

papaf 6y ago
Checking for nil receivers is rare and hardly idiomatic. I think newcomers are exposed to this behaviour now. For instance, it is step 12 in the tour of Go: https://tour.golang.org/methods/12 https://tour.golang.org/methods/12 I learnt Go before the tour was available and learnt a lot from going through the tour later on.
- Cthulhu_ 6y ago
  Oh wow, I hadn't seen that one yet. Gross, I don't want to have to check for nil receivers everywhere. I hope that's a wart that gets fixed. In Java land at some point we were taught to never use null anywhere, instead use the null object pattern. And in Go I'd like to extend that, never call a method on a nil receiver if you can avoid it. I think it should be up to the caller to do the nil check, IF the receiver can ever be nil.
  - masklinn 6y ago
    > Oh wow, I hadn't seen that one yet. Gross, I don't want to have to check for nil receivers everywhere. I hope that's a wart that gets fixed. Hahaha oh you sweet summer child. It's considered a feature. And since typed nils will never get fixed despite being an actual wart (though the FAQ tells you you're holding it wrong you idiot: https://golang.org/doc/faq#nil_error https://golang.org/doc/faq#nil_error) there's no chance nil receivers will get removed from the language.
  - spinny 6y ago
    this is probably a consequence of the language design. you also end up with things like this: https://play.golang.org/p/wgaLGOqFDZ9 https://play.golang.org/p/wgaLGOqFDZ9

papaf 6y ago

Checking for nil receivers is rare and hardly idiomatic. I think newcomers are exposed to this behaviour now. For instance, it is step 12 in the tour of Go: https://tour.golang.org/methods/12 https://tour.golang.org/methods/12 I learnt Go before the tour was available and learnt a lot from going through the tour later on.

Cthulhu_ 6y ago
Oh wow, I hadn't seen that one yet. Gross, I don't want to have to check for nil receivers everywhere. I hope that's a wart that gets fixed. In Java land at some point we were taught to never use null anywhere, instead use the null object pattern. And in Go I'd like to extend that, never call a method on a nil receiver if you can avoid it. I think it should be up to the caller to do the nil check, IF the receiver can ever be nil.
- masklinn 6y ago
  > Oh wow, I hadn't seen that one yet. Gross, I don't want to have to check for nil receivers everywhere. I hope that's a wart that gets fixed. Hahaha oh you sweet summer child. It's considered a feature. And since typed nils will never get fixed despite being an actual wart (though the FAQ tells you you're holding it wrong you idiot: https://golang.org/doc/faq#nil_error https://golang.org/doc/faq#nil_error) there's no chance nil receivers will get removed from the language.
- spinny 6y ago
  this is probably a consequence of the language design. you also end up with things like this: https://play.golang.org/p/wgaLGOqFDZ9 https://play.golang.org/p/wgaLGOqFDZ9