泛型的下一步

引言

距離我們上次編寫向 Go 新增泛型的可行性已經過去差不多一年了。現在是時候進行更新了。

設計更新

我們一直在不斷完善泛型設計草案。我們已經為它編寫了一個型別檢查器：一個可以按照設計草案解析使用泛型程式碼並報告任何型別錯誤的程式。我們已經完成了示例程式碼。 同時，我們也收集了許許多多人的反饋ーー謝謝你們提供了這些反饋！

基於我們得到的反饋，我們釋出一個更新的設計草案。最大的變化是我們放棄了contracts的概念。contracts和interface型別之間的差異令人困惑，因此我們嘗試消除這種差異。型別引數現在可以被介面型別的約束。現在允許介面型別包含型別列表，但只有在用作約束時才可以。在以前的設計草案中，型別列表是contracts的一個特性。更復雜的情況將使用引數化的介面型別。

我們希望人們會發現這個設計草案更加簡單易懂。

實驗性工具

為了幫助確定如何進一步完善設計草案，我們釋出了一個翻譯工具。這個工具允許開發人員檢查和執行使用設計草案的泛型版本開發的程式碼。它通過將泛型程式碼轉換為普通 Go 程式碼工作。這個翻譯過程有一些侷限性，但我們希望它能夠讓人們對 Go 泛型程式碼樣式有所瞭解。如果這個設計被接受，泛型的真正實現將會有不同的工作方式。 (我們才剛剛開始勾勒出直接編譯器實現的大概樣子。)

這個工具可以在 https://go2goplay.golang.org 的 Go Playground 上使用。這個 Playground 就像通常的 Go Playground 一樣，不過它支援泛型程式碼。

您也可以自己構建和使用該工具。它在主 Go 倉庫中的一個分支中。按照從原始碼開始安裝 Go 的說明進行操作。不過這些操作說明需要你檢查最新的 release 標記，而這裡我們需要執行git checkout dev.go2go。 然後按照指引構建 Go 工具鏈即可。

這個翻譯工具在 README.go2go 中有文件說明。

下一步

我們希望這個工具能給 Go 社群一個體驗泛型的機會。 我們希望通過這個工具瞭解兩件事情。

首先，泛型程式碼有意義嗎？感覺像 Go 的風格嗎？人們會遇到什麼樣的驚喜？錯誤訊息有用嗎？

其次，我們知道很多人說 Go 需要泛型，但是我們不一定知道泛型使用具體是什麼樣的場景。這個設計草案是否有效地解決了問題？如果有一個問題使你認為 “如果 Go 有泛型，我就可以解決這個問題” ，那麼在使用這個工具能解決你的問題嗎？

我們將使用從 Go 社群中收集到的反饋來決定如何前進。如果設計草案很受歡迎，並且不需要重大修改，那麼下一步這將是一個正式的語言變更提案。為了設定預期，如果所有人都對設計草案完全滿意，並且不需要進一步的調整，那麼最早泛型將會 2021 年 8 月釋出的 Go 1.17 進行新增。 當然，在現實中，可能會有不可預見的問題，所以這是一個樂觀的時間表; 我們不能作出任何明確的預測。

反饋

提供語言變化反饋的最好方法是在郵件列表 golang-nuts@googlegroups.com 上。郵件列表並不是完美的，但它們似乎是我們早期討論的最佳選擇。在撰寫設計草案時，請將[generics]放在主題行的開頭，並針對不同的具體主題使用不同的討論串。

如果你在泛型型別檢查器或者翻譯工具中發現了 bug，它們應該被提交到 Go 問題追蹤 https://golang.org/issue 中。 請以 cmd/go2go:. 作為標題的開頭。 注意，問題追蹤不是討論語言更改的最佳位置，因為它不提供討論串，也不適合長時間的對話。

我們期待著你的反饋。

致謝

我們還沒有結束，但是我們已經走了很長的路。如果沒有很多的幫助，我們無法到達這裡。

我們要感謝 Philip Wadler 和他的合作者，他們正式地思考了 Go 中的泛型，並幫助我們釐清了設計的理論方面。他們的論文 Featherweight Go 在受限的 Go 版本中分析泛型，並且他們在 GitHub 上開發了一個原型。

我們還要感謝那些對早期版本的設計草案提供了詳細反饋的人。

最後但卻很重要的一點就是，我們要感謝 Go 團隊的許多人，Go 問題追蹤的許多貢獻者，以及所有其他對早期設計草案分享想法和反饋的人。我們讀完了所有的文章，我們很感激。沒有你我們不會到達這裡。

原文：The Next Step for Generics