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

大家好,我是煎鱼。

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

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

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

快速背景

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

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

go 复制代码
v, err := computeTheThing()

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

go 复制代码
v, _ := computeTheThing()

相信大家都这么干过。(没错,经常翻代码看到...)

但是在很多有唯一返回值(例如:io.Closer.Closeproto.Unmarshal)的场景下,写习惯后,有的就顺手忽略了。

最常见的代码:

go 复制代码
_ = json.Unmarshal(jsonBlob, &eddycjy)

又或是:

go 复制代码
defer fd.Close()

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

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

如下代码:

go 复制代码
t := time.Now()
t.Add(10 * time.Second)  // Should be t = t.Add(...)

又或是:

go 复制代码
strconv.AppendQuote(dst, "eddycjy")  // Should be dst = strconv.AppendQuote(...)

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

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

期望的解决方案

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

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

如下 ignore 代码:

go 复制代码
go func() { ignore(fmt.Fprintln(os.Stderr, findTheBug())) }()

或是以下变形:

go 复制代码
go func() { ignore fmt.Fprintln(os.Stderr, findTheBug()) }()

又或是使用别的方式:

go 复制代码
go func() { _ fmt.Fprintln(os.Stderr, findTheBug()) }()

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

其他语言是如何处理的

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

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

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

核心团队回复

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

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

反对的原因是:

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

结论是:"我同意这个问题,但不同意建议的解决方案"。(煎鱼注:高情商发言人?)

总结

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

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

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

文章持续更新,可以微信搜【脑子进煎鱼了】阅读,本文 GitHub github.com/eddycjy/blo... 已收录,学习 Go 语言可以看 Go 学习地图和路线,欢迎 Star 催更。

推荐阅读

相关推荐
研究司马懿1 天前
【云原生】Gateway API高级功能
云原生·go·gateway·k8s·gateway api
梦想很大很大2 天前
使用 Go + Gin + Fx 构建工程化后端服务模板(gin-app 实践)
前端·后端·go
lekami_兰2 天前
MySQL 长事务:藏在业务里的性能 “隐形杀手”
数据库·mysql·go·长事务
却尘2 天前
一篇小白也能看懂的 Go 字符串拼接 & Builder & cap 全家桶
后端·go
ん贤2 天前
一次批量删除引发的死锁,最终我选择不加锁
数据库·安全·go·死锁
mtngt112 天前
AI DDD重构实践
go
Grassto4 天前
12 go.sum 是如何保证依赖安全的?校验机制源码解析
安全·golang·go·哈希算法·go module
Grassto6 天前
11 Go Module 缓存机制详解
开发语言·缓存·golang·go·go module
程序设计实验室7 天前
2025年的最后一天,分享我使用go语言开发的电子书转换工具网站
go
我的golang之路果然有问题7 天前
使用 Hugo + GitHub Pages + PaperMod 主题 + Obsidian 搭建开发博客
golang·go·github·博客·个人开发·个人博客·hugo