Named Go returns parameters

In Go you can write functions that have named result parameters.

Two examples from the spec:

func complexF3() (re float64, im float64) {
    re = 7.0
    im = 4.0
    return
}

func (devnull) Write(p []byte) (n int, _ error) {
    n = len(p)
    return
}

There some many advantages on using this syntax.

You don’t have to manually allocate the return variables, as having them named as result types, they are automatically initialized at their zero value for their type when the function begins.

Named return parameters do a very good job as implicit documentation: you know what the function is returning directly from its signature, as naming things help understand the code.

If there are multiple exit points from a function, you don’t need to write all the parameters, just return (called bare return). You still can list the returned values explicitly, and probably you should, to prevent having code hard to read. As suggested in The Go Programming Language:

[…] with many return statements and several results, bare returns can reduce code duplication, but they rarely make code easier to understand. […] Bare returns are best used sparingly

An example:

func something(n int) (ret int, m string, err error) {
    if n == 0 {
        err = errors.New("Houston, we have a problem!")
        return 0, "", err
    }

    ret = n + 100
    m = "Congratulations"

    return ret, m, err
}

or without bare returns:

func something(n int) (ret int, m string, err error) {
    if n == 0 {
        err = errors.New("Houston, we have a problem!")
        return
    }

    ret = n + 100
    m = "Congratulations"

    return
}

In both cases the code is cleaner and more readable than

func something(n int) (int, string, error) {
    var ret int
    var m string

    if n == 0 {
        err := errors.New("Houston, we have a problem!")
        return ret, m, err
    }

    ret = n + 100
    m = "Congratulations"

    return ret, m, nil
}

Beware the risk of shadowing a parameter with a new declaration inside the function.

So, when should you use them? When it makes sense to you in the overall design of a program. I’ll let The Go Programming Language reply with a quote:

[…] it’s not always necessary to name multiple results solely for documentation. For instance, convention dictates that a final bool result indicates success; an error often needs no explanation.

Additional resources: