大家好，我是煎魚。

大家學(xué)習(xí)和使用 Go 語言時(shí)，有一個(gè)神奇的概念：零值（zero-values）。零值這個(gè)名字是具體誰起的，又是從哪里先開始喊起的，已經(jīng)難以考究了。

每次有新同學(xué)剛開始轉(zhuǎn)語言，工程上總會(huì)提到這個(gè)，想要試圖改變零值。又或是沒考慮到，一旦程序用了 0 作為 default 值，又要兼容零值的問題。

今天給大家分享一個(gè)關(guān)于零值的新提案，目測已經(jīng)八九不離十了（在發(fā)布此文時(shí)，該提案已被正式 accepted）。

圖片

快速復(fù)習(xí)零值

基礎(chǔ)類型的例子如下：

func main() {
 var i int
 var f float64
 var b bool
 var s string
 fmt.Printf("%v %v %v %q\n", i, f, b, s)
}

輸出結(jié)果：

0 0 false ""

復(fù)合類型的例子如下：

type Person struct {
 Name   string
 Age    int
 Weight float64
}

func main() {
 var p Person
 var m map[int]string
 var s []string

 fmt.Printf("%#v\n%#v\n%#v\n", p, m, s)
}

輸出結(jié)果：

main.Person{Name:"", Age:0, Weight:0}
map[int]string(nil)
[]string(nil)

類型和零值的映射表格如下：

新提案：預(yù)聲明標(biāo)識符 zero

背景

事情的起因是：@Nathan Cormier 在社區(qū)提了吐槽和提案《proposal: builtin: zero function[1]》：

圖片

他表示：Go 語言目前提供了幾種獲取類型零值的方法，如果能有一種統(tǒng)一的方法來實(shí)現(xiàn)這一點(diǎn)，代碼的可讀性會(huì)更高。

有同學(xué)深思，哪來的幾種？其實(shí)可以：

var z MyType
return z

還可以：

return *new(MyType)

初始化結(jié)構(gòu)體后出來的都是零值。

緊接著就會(huì)遇到開頭提到的問題，你怎么知道這是零值，還是缺省值？難以直接判別。

更重要的是，這不太符合 Go 的設(shè)計(jì)哲學(xué)，又是多種途徑，還和缺省值產(chǎn)生混淆。顯然和主打工程的 Go 的發(fā)展路子不合。

解決方案

新增 zero 標(biāo)識符

這次經(jīng)過一番撕扯，最終是由 Go 核心團(tuán)隊(duì)負(fù)責(zé)人 @Russ Cox 出來主持大局，提出了新提案并一路向前。

圖片

Go 將會(huì)增加一個(gè)新的預(yù)定義標(biāo)識符 zero，它是一個(gè)無類型的零值，適用于數(shù)組和結(jié)構(gòu)體類型。

以下是 zero 的類型簽名：

// zero is a predeclared identifier representing the zero value
// for array and struct types.
var zero Type

他不會(huì)像 nil 一樣。我們可以對照看看 nil 的類型簽名：

// nil is a predeclared identifier representing the zero value for a
// pointer, channel, func, interface, map, or slice type.
var nil Type // Type must be a pointer, channel, func, interface, map, or slice type

Nil 受限于 chan、func、interface、map、slice、pointer 等類型。

zero 可賦值性規(guī)則

zero 的可賦值性規(guī)則如下：

• 絕大部分場景下，zero 可以分配給任何類型 T 的任何變量。（T 指的是結(jié)構(gòu)體）
• 不可以的場景，已經(jīng)具有短零（指的是：0、“”、nil）的變量，不可以分配。
• 泛型場景下，即使 T 是帶有 any 約束條件的類型參數(shù)，也是可以分配的。
• 上述提到的可賦值性，包含函數(shù)參數(shù)和返回值，例如：f(zero) 和 return zero, err 也是正常有效的，也能夠用于值比較。

可能會(huì)有的同學(xué)擔(dān)心，zero 和短零（0, "", or nil）產(chǎn)生沖突。對此可以放心。在設(shè)計(jì)的規(guī)則上：zero 在短零有效的任何地方都無效，所以在使用上不會(huì)產(chǎn)生混淆。

解決了什么問題

實(shí)際問題上，解決了以下幾點(diǎn)：

• 在通用代碼中需要引用零值，發(fā)現(xiàn)大家經(jīng)常建議使用 *new(T) 來做初始化。導(dǎo)致經(jīng)常要向新用戶解釋這一點(diǎn)非常麻煩。Go 需要更簡潔的方法。
• 在泛型代碼中便于與零值比較，在 cmp: add Or[2] 中出現(xiàn)了這一實(shí)際編碼訴求。
• 縮短錯(cuò)誤返回，新的 return zero, err 會(huì)比原有的 return time.Time{}, err 更好。

通用概念來講：

• 零值是 Go 中的一個(gè)重要概念。但某些類型對此還沒有具體的名稱，現(xiàn)在可以叫他 zero。
• Go 需要一個(gè)機(jī)制來將其值和零值進(jìn)行比較，來解決前文提到的缺省值和零值無法很好識別的問題。

一些問題和爭論

會(huì)有同學(xué)認(rèn)為，現(xiàn)有的 return _, _, err 會(huì)比 return zero, zero, err 更短并且感覺更好。（但在清晰程度上會(huì)不如 zero 和 nil）

也有同學(xué)會(huì)認(rèn)為自己寫一個(gè)這個(gè)實(shí)現(xiàn)也很簡單，是否有必要為此專門增加一個(gè) zero 預(yù)定義值？

可以用泛型如下實(shí)現(xiàn)：

func Zero[T any]() T {
    var v T
    return v
}

對此在很多提案上，都很容易陷入怪圈。有了泛型后，照實(shí)現(xiàn)來講，什么都可以自己寫一份。

也會(huì)有一派認(rèn)為以后判斷錯(cuò)誤類型要變成：

if err != zero {
  ...
}

會(huì)非常奇怪。以后可能會(huì)出現(xiàn) if err != nil 和 if err != zero 的奇怪代碼場景。

注：這個(gè)場景是假定 zero 標(biāo)識符能適用于所有的數(shù)據(jù)類型下才會(huì)出現(xiàn)。本次并不存在。

總結(jié)

目前的社區(qū)討論比較發(fā)散，認(rèn)為 zero 標(biāo)識符未來也可以取代所有的零值。但從提案內(nèi)容和提交的 SPEC CL 來看，@Russ Cox 一直針對的是數(shù)組和結(jié)構(gòu)體的零值場景去使用 zero 標(biāo)識符。

這個(gè)提案已經(jīng)進(jìn)入到最終階段，已經(jīng)被正式接受，基本跑不了了。

圖片

以后我們在不同類型下對零值判斷，可以基于：

雖然在使用上，做了一定的使用場景的切分，也就是只有數(shù)組和結(jié)構(gòu)體類型使用 zero 標(biāo)識符。但對于寫 Go 用戶而言，認(rèn)知上是會(huì)存在明確混淆的。

以后你給其他同學(xué)解釋零值，解釋起得區(qū)分兩種場景來介紹。我感覺還不如 zero 標(biāo)識符一統(tǒng)零值天下。但很可惜，本次提案暫時(shí)并沒有這個(gè)計(jì)劃。

參考資料

[1]proposal: builtin: zero function: https://github.com/golang/go/issues/60695

[2]cmp: add Or: https://github.com/golang/go/issues/60204#issuecomment-1550369151