5 ms·

Like Swift, how once you check if a pointer (not integers, strings, and non-nullables) is null, the compiler knows from that point on the variable cannot be nul

• klodolph 5y ago
  Go already does that... if you have an "if x == nil { return }" at the top of your function, then the compiler knows that x != nil below that point, and elides nil checks. Like, I'm not trying to be cute here, but the point of having a "non-nullable type" is that you can get an error message when you use a nullable type in its place. However, if you're not talking about non-nullable types and just about whether the compiler knows a value is nil, well, the compiler knows that.
  • richardfey 5y ago
    > elides nil checks. Are you sure? This would only work in a world with a single goroutine.
    • chrisseaton 5y ago
      It’s a basic optimisation. Java does it as well, for example, and it’s safe. But it’s not part of the type system and it’s not what people here are talking about.
    • simiones 5y ago
      It's more complex in practice, since you need to also check that the compiler needs to see the entire lifetime of the variable to check if it's not modified asynchronously, as you say. But for many common use cases, this is not hard to confirm, especially since the Go compiler has access to the entire source code of the entire program (unlike in C++, Java, etc).
  • adrianN 5y ago
    It would be nice if the compiler had a mode where it issued a warning if it doesn't know that a pointer is not nil.
  • welder 5y ago
    Yea, I meant the ability to declare functions that only accept non-nullable args. For ex: You have a chain of function calls, A -> B -> C -> D, where B, C, and D only accept a non-nullable arg then you can save the mental load of checking for null in 3 functions. Only A would need to check the var for null before calling B with that var. 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.
    • tsimionescu 5y ago
      > 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) a and b can't be nil, c can. 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).
      • ebingdom 5y ago
        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.
        • tsimionescu 5y ago
          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.
      • rowanG077 5y ago