|
| ▲ | oconnor663 37 minutes ago | parent | next [-] |
| Some weird nils don't compare equal to other nils. It's surprisingly easy to construct the weird kind by accident, because the conversion is automatic and invisible. |
|
| ▲ | kevinmgranger 2 hours ago | parent | prev | next [-] |
| Another reason why it's worse is how it breaks logical laws thanks to the nil interface bug: https://go.dev/doc/faq#nil_error Well, they'll call it a design decision, not a bug. I guess I'm being charitable. |
|
| ▲ | treis 5 hours ago | parent | prev | next [-] |
| It sets primitives to 0, "", false etc. Which is almost always but not always fine. And if they're complex objects you still get NPEs To get true nullable fields you need to use pointers. That's a whole topic in itself but they're awkward. It's much worse than true nullable objects that your compiler can check for NPEs. It throws fewer NPEs but at the expense of data integrity where you don't know if your 0 is actually a 0 from the user or a null. |
| |
| ▲ | Lvl999Noob 3 hours ago | parent [-] | | What if Go went all the way? Referencing a zero pointer (nil) gives you the zero value of the pointed to type. If you try to access a zero map, it tries to deference the zero pointer to the underlying buffer. The zero pointer gives you the zero slice with zero length. The presence check fails without crashing and you get some pretension of reasonable behaviour. | | |
|
|
| ▲ | MintPaw 2 hours ago | parent | prev [-] |
| I think there's a large subset of programmers now who consider null checking (or even the existence of null) to be bad, and prefer something else like exceptions or option types. I don't get it personally. |
| |
| ▲ | chuckadams 39 minutes ago | parent [-] | | The existence of null is not the problem, it’s when null populates every single non-primitive type, making every access into a logic bomb unless explicitly checked. When null is a distinct type, there’s no problem at all. |
|
