4 ms·
> If it is my discipline to add null guards or have runtime explosions I consider the nulls to be implicit. But they're still explicit nulls. You seem to be s
by coder543 6y ago
> If it is my discipline to add null guards or have runtime explosions I consider the nulls to be implicit.
But they're still explicit nulls.
You seem to be saying that only implicit nulls require null guards, but that's just not what that means (as far as I have learned).
You seem to hate nullability as a concept, which is fine, but that's different from hating implicit nullability.
> That you find as much runtime problems with unwrap/expect in Rust (which have a lot of red tape on them in API docs) as with "missing null guards" in Go, is great for you, but to me that does not make it a good design choice in Go.
It's also a comment on how NPEs are just not a common hazard in Go compared to my past experiences with Java, especially when combined with good editors and linters.
- wtetzner 6y ago> But they're still explicit nulls. Except that there may be other reasons to use pointers than just nullability. And in that case, there's no mechanism to specify whether or not the thing being pointed to is nullable. I think that's where the implicitness in question comes in.
- cies 6y agoExplicit to me is when I can see from the return type it is or isnt nullable AND that i have to deal with the null case explicitly (so nullableUser.lastName() errors out as I cannot call lastName() on null). But I might well be mistaken.