Nil Safety in Go

[krupal shah]

Are there any plans for including nil aware operators in Go. Like swift's optional and Dart's null aware operators (?,?.)

f, err := os.Open(fileName)
if err != nil {
    return err
}

....

....

This would make rror handling very easy and consice:

f, err := os.Open(fileName)
if err? return err
....
....

Also this would bring nil safety in a  language.

[Mikael Gustavsson]

You might be interested in: https://github.com/tcard/sgo

[krupal shah]

Thanks Mikael. I'll definitely look at it.

[Henry]

I do think that language-level nil check for function arguments is potentially useful. It could be something like this:

//will not compile if arg is nil
func MyFunction(arg MyInterfaceOrMapOrSliceOrPtr){
    ...
}

//will compile even if arg is nil because nil is allowed
func MyFunction(arg MyInterfaceOrMapOrSliceOrPtr?){
    ...
}

That way the code can focus on the actual problem to be solved, and not cluttered with various nil check.

[Dave Cheney]

Nil isn't as big a problem in Go as it is in other languages because we don't have a tradition of returning nil as a signal that an error occurred.

[Val]

I like it that in Go you can have a nil method receiver, and handle it in a sensible, non crashing way.
The same isn't true when accessing a field through a nil pointer, though.

[Viktor Kojouharov]

We kind of do, actually. It seems that almost any api that works with pointers and returns a pointer/error tuple, will return nil as the pointer value if there's an actual error.

[Damian Gryski]

On Sunday, May 29, 2016 at 5:01:20 PM UTC+2, Viktor Kojouharov wrote:

We kind of do, actually. It seems that almost any api that works with pointers and returns a pointer/error tuple, will return nil as the pointer value if there's an actual error.

But then that means you're using the return value without checking the error.

Damian

[Dave Cheney]

I don't believe that is true. The contract for almost all functions and methods that return an error value is that the caller cannot assume anything about the state of those other return values without first checking the error. If there is an error, then those other values are unknown and shouldn't be used.

[jonathan...@gmail.com]

I agree the nil problems in golang are not as large as other languages.

However it seems that there are plenty of cases where the compiler could be a champ and catch a lot (but not all)? Can the SSA work being done enable any nil checks?

[Paul Borman]

The problem is that nil can be a perfectly acceptable receiver, and sometimes (as documented for the function/method) you may get a value and and error.

For example, the documentation for an io.Reader states:

Callers should always process the n > 0 bytes returned before considering the error err. Doing so correctly handles I/O errors that happen after reading some bytes and also both of the allowed EOF behaviors.

Granted, n is an int and not a pointer, but it is wonderful example of getting back a value and an error.

I think static analysis will not help much.  There is no way in the language to know if a nil value is valid or not.  Consider the simple code of:

        var p *SomeType

        p.Method()

The compiler can make no assumptions about p since Method may indeed handle a nil receiver.  Yes, the compiler could reach down into Method and check if all paths eventually lead to an unrecovered panic, but as long as one path does not, the nil may be valid.  I am not sure the (very small) gain is worth the effort here.

I would be much happier if the compiler could figure out that given:

        const showDebug = false

        var debug(f string, v ...interface{}) {

                if showDebug {

                        fmt.Printf(f, v...)

                }

        }

and then

        debug("%s: %v\n", foo.Name, foo.SomeExpensiveCall())

that if foo.SomeExpensiveCall() has no observable side effects (other than returning a value) that it needn't even be called as it's value will never be productively used.

    -Paul

--
You received this message because you are subscribed to the Google Groups "golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.