Go 部落格
泛型語言的下一步
簡介
自我們上次撰寫關於增加 Go 泛型語言可能性的文章已屆滿一年左右。是時候提供更新資訊了。
更新設計
我們持續改善泛型語言設計草稿。我們為其撰寫類型檢查器：這是一個可以根據設計草稿分析使用泛型語言的 Go 程式碼並報告任何類型錯誤的程式。我們撰寫了範例程式碼。我們也收集了來自許許多多人的回饋 - 感謝您的提供！
根據我們的所學，我們釋出了更新的設計草案。最大的改變是我們放棄了合約這個想法。合約和介面類型之間的差異令人困惑，因此我們消除了這種差異。類型參數現在受到介面類型約束。介面類型現在可以包含類型清單，但前提是作為約束使用；在之前的設計草案中，類型清單是合約的一個功能。較複雜的案例將使用參數化介面類型。
我們希望人們會發現此設計草案更簡單、更容易理解。
實驗工具
為了精進設計草案，我們決定釋出一個轉譯工具。這是一個允許人們類型檢查和執行使用設計草案中描述的泛型版本所寫程式碼的工具。它的運作方式是將泛型程式碼轉換為一般 Go 程式碼。這樣的轉譯過程會有些限制，但我們希望它足夠讓大家對泛型 Go 程式碼的運作有所了解。如果泛型被接受加入語言中，泛型的實際實作方式將有所不同。（我們才剛開始勾勒出直接編譯器實作的可能樣貌。）
這個工具可以在 Go 遊樂場的一個變體中取得：https://go2goplay.golang.org。此遊樂場的運作方式與一般的 Go 遊樂場相同，但它支援泛型程式碼。
您也可以自行建立並使用這個工具。它可以在 Go 主要存放庫的分支中取得。請遵循從原始碼安裝 Go 的說明。當說明指示您結帳最新發布標籤時，請改為執行 git checkout dev.go2go。然後，按照指示建立 Go 工具鏈。
轉譯工具在README.go2go中說明。
後續步驟
我們希望這個工具能讓 Go 社群有機會實驗泛型。我們希望了解兩件主要事項。
首先，泛型程式碼是否有意義？它是否覺得像 Go？人們會遭遇哪些驚喜？錯誤訊息是否有用？
其次，我們知道很多人說 Go 需要泛型，但我們並不完全確定這表示什麼意思。這份設計草案是否用有用的方式解決問題？如果有一個問題讓您認為「如果 Go 有泛型，我就能解決它」時，您是否能使用這個工具解決這個問題？
我們將使用從 Go 社群獲取的意見回饋來決定如何繼續前進。如果是設計草案獲得好評且不需要重大變更，下一步將是 正式語言變更提案。如設定預期，如果每個人都完全滿意設計草案且不需要任何進一步調整，最早將泛型加入到 Go 的時間將會是預計於 2021 年 8 月發行的 Go 1.17 版。當然，實際上可能會有預料之外的問題，因此這是個樂觀的時程表；我們無法做出任何明確預測。
意見回饋
提供語言變更意見回饋的最佳管道將會是寄信到郵件清單 golang-nuts@googlegroups.com。寄信清單並不完美，但它們似乎是我們進行初步討論的最佳選擇。在撰寫關於設計草案時，請在主旨列開頭加上 [generics]，並為不同的特定主題開始不同的討論串。
如果你在泛型類型檢查器或轉換工具中發現錯誤，則應該在 go.dev/issue 的標準 Go 問題追蹤器中將這些錯誤送出。請以 cmd/go2go: 開頭。請注意，問題追蹤器並非討論語言變更的最佳場所，因為它不提供串連，而且不適合用於冗長的對話。
我們期待收到你的意見回饋。
感謝
我們尚未完成，但我們走了一段很長的路。沒有許多人的幫助，我們無法走到這裡。
我們要感謝 Philip Wadler 和他的合作者正式思考 Go 中的泛型，並協助我們釐清設計的理論面向。他們的論文 輕量級 Go 在受限版本的 Go 中分析泛型，且他們已在 GitHub 開發出一個原型。
我們也要感謝 那些人，他們對設計草案的先前版本提供了詳細的意見回饋。
最後但絕對不是最不重要的一點，我們要感謝 Go 團隊中的許多人、許多對 Go 問題追蹤器有貢獻的人，以及所有在先前設計草案中分享點子和意見回饋的人。我們讀了你們的所有意見，並且我們表示感謝。沒有你們，我們無法走到這裡。
下一篇文章：保持模組的相容性
前一篇文章：Pkg.go.dev 是開源的！
部落格首頁