proposal: spec: require return values to be explicitly used or ignored (Go 2)

[bcmills]

Today, if a Go function returns both a value and an error, the user must either assign the error to a variable

v, err := computeTheThing()

or explicitly ignore it

v, _ := computeTheThing()

However, errors that are the only return value (as from io.Closer.Close or proto.Unmarshal) or paired with an often-unneeded return value (as from io.Writer.Write) are easy to accidentally forget, and not obvious in the code when forgotten.

tx.Commit()  // Store the transaction in the database!

The same problem can occur even when errors are not involved, as in functional-style APIs:

t := time.Now()
t.Add(10 * time.Second)  // Should be t = t.Add(…)

strconv.AppendQuote(dst, "suffix")  // Should be dst = strconv.AppendQuote(…)

For the few cases where the user really does intend to ignore the return-values, it's easy to make that explicit in the code:

_, _ = fmt.Fprintln(&buf, v)  // Writes to a bytes.Buffer cannot fail.

go func() { _, _ = fmt.Fprintln(os.Stderr, findTheBug()) }()

And that transformation should be straightforward to apply to an existing code base (e.g. in a Go 1-to-2 conversion).

On the other hand, the consequences of a forgotten error-check or a dropped assignment can be quite severe (e.g., corrupted entries stored to a production database, silent failure to commit user data to long-term storage, crashes due to unvalidated user inputs).

---

Other modern languages with explicit error propagation avoid this problem by requiring (or allowing API authors to require) return-values to be used.

• Swift warns about unused return values, but allows the warning to be suppressed if the @discardableResult attribute is set.
  • Prior to a change in Swift 3, return-values could be ignored by default (but a warning could be added with @warn_unused_result)
• Rust has the #[must_use] attribute.
• C++17 has the [[nodiscard]] attribute, which standardizes the longstanding __attribute__((warn_unused_result)) GNU extension.
• The ghc Haskell compiler provides warning flags for unused results (-fwarn-unused-do-bind and -fwarn-wrong-do-bind).
• OCaml warns about unused return values by default. It provides an ignore function in the standard library.

I believe that the OCaml approach in particular would mesh well with the existing design of the Go language.

I propose that Go should reject unused return-values by default.

If we do so, we may also want to consider an ignore built-in or keyword to ignore any number of values:

go func() { ignore(fmt.Fprintln(os.Stderr, findTheBug())) }()

or

go func() { ignore fmt.Fprintln(os.Stderr, findTheBug()) }()

or

go func() { _ fmt.Fprintln(os.Stderr, findTheBug()) }()

If we use a built-in function, we would probably want a corresponding vet check to avoid subtle eager-evaluation bugs:

go ignore(fmt.Fprintln(os.Stderr, findTheBug()))  // BUG: evaluated immediately

---

Related proposals
Extending vet checks for dropped errors: #19727, #20148
Making the language more strict about unused variables in general: #20802
Changing error-propagation: #19991

[ianlancetaylor]

A point of clarification: when you wrote

_ = fmt.Fprintln(&buf, v)

did you mean to write

_, _ = fmt.Fprintln(&buf, v)

or did you forget that fmt.Fprintln returns two values? That is, is your proposal intended to cover a function like fmt.Fprintln that returns two values? I can't quite tell.

[bcmills]

That was a typo on my part. Fixed, and added a suggestion for an ignore builtin.

[ianlancetaylor]

While I certainly sympathize with the concerns here, I just want to state that 1) I think that wrapping expressions in ignore makes code harder to read by burying the lede; 2) in a language that values simplicity having the canonical hello, world example start with _, _ = seems to me to be unfortunate.

That is, I'm on board with the problem, but not with the proposed solutions.

[bcmills]

ignore as a keyword rather than a builtin might address the lede-burying problem somewhat. IMO,

    ignore fmt.Println("Hello, world")

is a bit clearer than

    ignore(fmt.Println("Hello, world"))

But I agree that those are both valid concerns, and I'd be thrilled if we could find some way to address the underlying problems (missed values in general, and missed errors in particular) that resolves those concerns.

[bcmills]

I should note a point that I forgot to make in the original post (now edited to add): this isn't just a problem for errors, but also for functional-style APIs such as time.Time.Add or strconv.Append*. The missed return value is sometimes the only clue the reader has as to whether an API is functional or mutative.

[pborman]

I know this has been discussed before, multiple times. The concern usually is: OMG, they did defer fd.Close() and there might have been an error. If fd is read only then the close error provides no useful information. Either you read the data you wanted or you didn't. Any meaningful errors are captured during read.

go ignore fd.Close()
ignore go fd.Close()

What about maps? Is it okay to ignore the bool, or would I have to always add the , _ to the left hand side. If that is the case then you can't write if myBoolMap[x] { anymore, it becomes if ok, _ := myBoolMap[x]; ok {.

Just how many programs would this proposal break? This seems like a Go 2.0 feature as it breaks the compatibility guarantee. I guess you could test that by writing a go vet function to do this and then run it first over the standard library, and then over random libraries from github or over the Go code internal at your company.

[bcmills]

What about maps?

Map lookups would still support both the one-value and two-value forms, but ignoring the result of a map lookup entirely would (continue to) be an error.

These are ok.

if m[x] {

if _, ok := m[x]; ok {

if y := m[x]; y {

if y, _ := m[x]; y {  // Verbose, but ok.

This one is not ok, because the result is ignored entirely. The compiler already rejects it today (https://play.golang.org/p/0WMEDVzY44).

m[x]

[bcmills]

Just how many programs would this proposal break?

Most of them. It is labeled "Go2" for good reason. :)

[robpike]

Having lived through the

(void)printf("hello, world\n");

era, I firmly believe some heuristics in vet are a better way to approach this problem. That's what #20148 is about.

Like Ian, I appreciate the concern but dislike the proposed remedy.

[nerdatmath]

ISTM we don't really want to ignore errors; I think in most of these cases we really want to panic in case of error, because the programmer believes an error is not possible, or that a meaningful response to an error doesn't exist. So it seems like we want a generic Must. This might seem weird, but what if the exclamation point (!) could be used as a postfix operator to conditionally panic. If the value is a bool, panic if it's not true, and if it's an error, panic if it's not nil. It could also be used with multiple return values, only looking at the last value. Since it's postfix it avoids burying the lede, but indicates the programmer understands they're ignoring an error value. (!) should always consume one or more values but never return anything, and should fail to compile if the type of the last value passed in is not bool or error.

func main() {
    fmt.Println("Hello, world!")!
}

I guess we would also want go f(x)! and defer f(x)! to be equivalent to go func(z T) { f(z)! }(x) and defer func(z T) { f(z)! }(x).

[bcmills]

So, what are the cases where it really is appropriate to ignore all of the return values of a function?

These are always appropriate to ignore:

• Write methods on a bytes.Buffer or hash.Hash (which always return len(p), nil).
• (ioutil.NopCloser).Close (but in that case why use the NopCloser at all?).
• (expvar.Map).Init (which returns the receiver).

These are conditionally appropriate:

• Close on an io.ReadCloser implementation (if it is not also writable).
• (io.Closer).Close, (exec.Cmd).Wait, and builtin.recover (if the current function is already returning some other error).
• Transitive writes to a bytes.Buffer (if the bytes.Buffer detail is obvious enough to avoid bugs if the code is refactored).
• Transitive writes to os.Stdout or os.Stderr, including the fmt.Print functions (if the program is small enough and has few enough dependencies that SIGPIPE is obviously not ignored, and/or the program will obviously exit soon).
• atomic.Add functions (if overflow is benign or impossible).
• math/big operator methods (if the receiver is used elsewhere).
• Container insertions (if the caller is storing an element for later or doesn't care whether it is stored).
  • (*ring.Rink).Link
  • (*list.List).{InsertBefore,InsertAfter}
  • (*sync.Map).LoadOrStore
  • (reflect.Value).TrySend
• Container deletions (if the caller already has the element or is no longer interested in it)
  • heap.Remove
  • (*ring.Ring).Unlink
  • (*list.List).Remove
• time.AfterFunc (if the caller will never cancel the operation).
• runtime.GOMAXPROCS and runtime.SetMutexProfileFraction (if the argument is nonzero and the previous value will not be restored).
• Slice operations:
  • copy and reflect.Copy (if the number of bytes to be copied is already known)
  • append (if the argument is known to fit in the slice)
• (reflect.Value).Call and (reflect.Value).CallSlice (if the function is known to have no return-values, or known to be one of the above cases)

Unclear to me:

• (sql.Tx).Rollback

[rodcorsi]

As you say, we have few cases where it is appropriate to ignore the return value, and we can do this clearly with an attribute.

func Fprintln(w io.Writer, a ...interface{}) (n int, err error) optional