Re:Things Go needs more than generics
by tsimionescu on Monday October 04, 2021 @03:11AM
(#28743975)
> With Go, you have to check for nil in every function even if all your callers already check for nil. That's because Go can't declare a function's arg as non-nullable type.
I have no idea what you mean.
func foo(a int, b someStruct, c *someStruct)
Now, it is true that there are multiple reasons for using a pointer aside from supporting nil (ability to modify, optimization not to copy a huge object).
I'm not who you're responding to, but the fact that interfaces/pointers (among other things) are nullable and there is no way to make them non-nullable is a problem with Go. A lot of bugs in Go programs are due to calling methods on those types and getting a null pointer error.
Your claims are correct, but it feels like you're missing the point they are (ineffectively) making.
Re:Things Go needs more than generics
by tsimionescu on Monday October 04, 2021 @03:37AM
(#28744124)
Sure, that is why I added my second paragraph recognizing that things aren't all great, but still Go is a little better than Java for example in this area, where literally every non-primitive type is nullable.
Aren't you proving his point? You cannot mark c as non-nil.
Re:Things Go needs more than generics
by tsimionescu on Monday October 04, 2021 @05:06AM
(#28744632)
Yes, but still a and b are non-nil. My point was that Go is not like Java, where literally all non-primitive types are nullable.
What if I want to pass a pointer into the function (maybe I want to mutate the object), but I want that pointer to be non-nil?
You make it seem like value types solve this problem, but they don't. C also has the same thing you're talking about, but it still has nullability problems.
I think other comments are not even asking for anything complex. Something akin to C++'s references (which cannot be null) would already be a step forward.
I was only talking about pointers and interfaces, not primitive types. Yes A and B can't be nil, but I was only talking about C. Pointers (C) are what cause crashes in Go programs when using them without checking if they're nil first.
The safety is contagious, preventing crashes from nil pointer dereferences at runtime. For ex: 99% of your program is functions accepting only non-nullable types then 99% of your program is guaranteed to not crash from nil pointer deref.
With Go, you have to check for nil in every function even if all your callers already check for nil. That's because Go can't declare a function's arg as non-nullable type.