Go新提案：返回值应该明确使用或忽略？

之前在写 Go 代码时 IDE 经常会提示。外加我有一个朋友他团队内 CodeReview 也会遇到一些方法的返回值，处理不处理的问题。一开始大家还会讨论一下，久而久之基本也就麻木了。

假期时翻资料学习时，看到了 Go 社区这个相关的 issues#20803^[1]。之前已经有大佬提过类似的疑惑，Go 团队也进行了回复。

官方算是给了一个初步的定论，今天分享给大家。和煎鱼一起学习！

快速背景

现在我们写 Go 程序时，如果函数或方法同时返回了返回值和错误参数，用户（程序员）必须要做出一些处理。

最经常的返回 error 参数的场景。如下代码：

v, err := computeTheThing()

或是明确的忽略他。如下代码：

v, _ := computeTheThing()

相信大家都这么干过。（没错，经常翻代码看到...）

但是在很多有唯一返回值（例如：io.Closer.Close、proto.Unmarshal）的场景下，写习惯后，有的就顺手忽略了。

最常见的代码：

_ = json.Unmarshal(jsonBlob, &eddycjy)

又或是：

defer fd.Close()

看了直呼好家伙...业务代码写的久的同学应该知道不可信任原则。我是经常遇到有人这么写，结果没有记错误信息，查半天没查到哪里出问题的。

即使不是错误参数的处理。在其他 API 中也有类似的问题。

如下代码：

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

又或是：

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

总而言之，提案作者 @Bryan C. Mills 认为 “忘记” 进行错误检查或丢弃赋值的后果可能相当严重。

可能会出现如下问题：存储到生产数据库中的数据被破坏、用户数据无法提交到存储中、因未验证用户输入而导致程序崩溃等问题。

期望的解决方案

提案作者 @Bryan C. Mills 给出思路：建议 Go 默认拒绝未使用的返回值。

配合的解决方式是增加 ignore 内置关键字或其他方式来忽略任意数量的返回值。

如下 ignore 代码：

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

或是以下变形：

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

又或是使用别的方式：

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

简而言之，就是较为显式的指定来忽略。

其他语言是如何处理的

• Swift 会对未使用的返回值发出警告，但如果设置了 @discardableResult 属性，则允许抑制该警告。
• 在 Swift 3 中进行修改之前，默认情况下可以忽略返回值（但可以使用 @warn_unused_result 添加警告）。
• Rust 有 #[must_use]^[2] 属性。
• C++17 有 [[nodiscard]]^[3] 属性，它将长期存在的 __attribute__((warn_unused_result)) GNU 扩展标准化。
• ghc Haskell 编译器为未使用的结果提供了警告标志（-fwarn-unused-do-bind 和 -fwarn-wrong-do-bind^[4]）。
• OCaml 默认会对未使用的返回值发出警告。它在标准库中提供了一个 ignore^[5] 函数。

提案作者认为 OCaml（这是一个函数式、指令式、模块化、面向对象的通用的编程语言）提供 ignore 函数的方式与 Go 最为贴合。

因此他提出的提案和方向也与此语言保持基本一致。

核心团队回复

Go 核心团队成员之一的老大哥 @Ian Lance Taylor 和 Go 创始人 @ Rob Pike，直接发了张好人卡给提案作者。（尴尬了...）

翻译过来的关键意思是：“我很同情大家的担忧，但你这个解决方案不够好”。

反对的原因是：

• 降低代码可读性：认为用 ignore 函数来包装表达式会掩盖代码的主要内容，从而增加代码的阅读难度。
• 这个例子不够好：在一门重视简洁性的语言中，用 _, _ = 开头的典型例子 hello, world 在我看来是很不幸的。

结论是：“我同意这个问题，但不同意建议的解决方案”。（煎鱼注：高情商发言人？）

总结

通篇看下来，其实 Go 核心团队是较为认可这个问题的存在。但是既要也要还要的模式下，一时半会也找不到更好的解决思路。

同时许多社区内提出的解决思路都会一定程度的破坏 Go 现有的兼容性保障，让这件事变得前后都 “复杂” 了起来。

因此在后续中，Go 官方更推荐使用 vet 等 linter 工具检测来规避这个问题。

推荐阅读

• Go 是 Google 的语言？核心成员的内部视角
• 创始人 Rob Pike：Go 做对了什么，才能如此成功？
• Go 泛型有没有可能在后期改为 <> 尖括号？