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.

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.

> 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).

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.

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.

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.

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.

> elides nil checks.

Are you sure? This would only work in a world with a single goroutine.

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.

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).