[3d3mon]

Null references do make reading code more complex for the user since every function call must be prefaced with a null check. If I make a function call in every line of my code adding all the null checks would easily double my line count, burying my code in Java-like verbosity (ok not that much but you get the idea). I suppose a good IDE could help with this if option types remain unavailable.

Another common complaint with null references is that there is no compile-time type safety that you get with option types. The go team could mitigate this by having the compiler check for possible null references that may not have been caught and emit warnings or refuse to compile.

[enneff]

> Null references do make reading code more complex for the user since every function call must be prefaced with a null check.

Well, the Go code I see doesn't look like this, so that can't be right.

[azth]

So "right" Go code ignores checking references that can be null so that it can blow up at run time? That can't be safe.

[enneff]

No, it's just that's not how it works.

For instance,

    s, err := server.New()
    if err != nil {
      // handle error
    }
    s.Foo()

You're not going to check that s != nil before calling s.Foo, even though s is probably a *server.Server and could be nil. But it won't be, if the New function is correct. Yes, the compiler doesn't guarantee that New gives you a non-nil pointer, but it also doesn't guarantee a lot of things about the behavior of the program.

[azth]

I was mainly referring to function arguments. Any function that takes a pointer type has to have null checks at the beginning, since any of the pointer arguments may be null.

[dsymonds]

"has to" is a bit strong. The standard assumption is that pointer arguments should be set (or the function is documented otherwise), and the responsibility is left with the caller. It just bubbles out from there.

[mietek]

Yes, this is the way things have been done since 1965. It sounds simple enough, but as it turns out, in complex systems, this is a common cause of defects.

Programmers forget to check things all the time. Assumptions made in different areas of the code, by different programmers, at different times, do not always hold.

Fortunately, computers are good at remembering to check things. We just need to allow them to do so.