預計在 Go 1.18 中內建泛型

Hi，大家好

如果沒有意外的嚴重問題，Go 1.18 將包括對泛型的支援。泛型是 Go 1 釋出以來最重要的變化，當然也是我們有史以來最大的一次語言變化。這封郵件稍稍解釋了泛型的加入對我們和使用者的意義。

任何 Go 的新功能，無論是語言還是庫，都帶有不確定性：如何使用它的不確定性，如何不使用它的不確定性，以及那些不確定的已經通過了現有的測試的微妙 Bug。泛型也不能避免這種不確定性；事實上，因為它是一個大型的新功能，所以不確定性也相應的更大。

因為我們不知道使用泛型的最佳實踐是什麼，所以我們的文件將無法就何時使用泛型和何時不使用泛型給出清晰明確的答案。我們仍然可以並將給出粗略的指南。作為比較，我們是在不間斷地寫了一整年的 Go 程式碼後，才寫出了 Effective Go 的最初版本。我們在泛型方面還沒有同樣的經驗，所以我們當然會提供關於如何使用泛型的文件，但我們不能提供任何關於風格和最佳實踐的規範。因為我們目前還不瞭解他們。

因為我們不知道編寫泛型包的最佳實踐是什麼，所以我們釋出的最初的泛型程式碼 -- 特別是通過提案程式的 maps 和 slices 包 -- 將首先落在 golang.org/x/exp 中，並且不保證向後相容。一旦我們有了更多的經驗，我們希望能將其中一些包移入標準庫中。比較特別的是 constraints 包，它是編寫某些通用程式碼的基礎，將在 Go 1.18 中被新增到標準庫中。

因為我們目前沒有任何關於泛型的生產實踐經驗，所以我們會在釋出說明中明確指出，在生產中使用泛型的時候應該適當謹慎。這並不是對團隊出色工作的批評。這只是因為泛型與大多數 Go 的變化不同。不便於觀察。當我們重寫垃圾收集器或改變呼叫約定時，我們會在 Google 的測試和生產中使用新的實現來執行所有 Go 程式，這樣就能很好地實踐變化並發現難以發現的 Bug。相比之下，用正在進行中的 Go 1.18 工具鏈重新構建非泛型程式碼並沒有實踐對泛型的支援，這意味著我們無法建立同樣的信心。

綜上所述，Go 1.18 與其他 Go 1.x 版本一樣具有向後相容的承諾：我們不會破壞用 Go 1.18 構建的程式碼，包括使用泛型的程式碼。在最壞的情況下，如果我們發現 Go 1.18 的語義有一些致命的問題，並需要改變它們（例如在 Go 1.19 中），我們將使用 go.mod 檔案的 go 行來確定該模組中的原始檔是期待 Go 1.18 還是 Go 1.19+ 語義。(我們希望不這樣做！)

我們預計一些包的作者會急於採用泛型。如果您正在更新您的軟體包以使用泛型，請考慮將新的泛型 API 隔離在自己的檔案中，併為 Go 1.18 構建標記（//go:build go1.18），以便 Go 1.17 使用者可以繼續構建和使用非泛型部分。

同樣值得注意的是，第三方工具可能不會在 Go 1.18 釋出時完全支援泛型。我們正在與許多工具的作者交談，並試圖確保他們得到適當的更新，但各個工具都有自己的時間表。

我們收到的一個常見的問題是：考慮到所有這些不確定性，為什麼不把泛型變成可選使用？答案是，在這一點上，減少不確定性的唯一方法是讓泛型預設可用。當我們在 Go1.5 版本中讓 vendoring 功能變成可選使用時，當時幾乎沒有人真正使用它，直到 Go1.6 版本預設開啟它。所以 Go1.5 版本沒有減少 vendoring 功能作用的不確定性。另一方面，Go 1.5 版本無疑將生態系統分為 "在標準 Go 下執行的程式碼 "和 "在啟用 Vendoring 後執行的程式碼"。我們希望這次儘可能地避免這種結果。

這裡每個人可以做的最重要的事情就是寫一些通用程式碼，如果你發現了 bug，不清楚的編譯器錯誤等等，請讓我們知道。我最近寫了一些通用資料結構，對整體的體驗非常滿意。我希望你也會這樣；如果沒有，請提交 bug。謝謝!

Best, Russ

原文地址： https://groups.google.com/g/golang-dev/c/iuB22_G9Kbo/m/7B1jd1I3BQAJ