文 | 局長

前段時間，Go 語言之父 Rob Pike 在 Go 程式碼倉庫提交了一個 issue （#48918），建議不要改動 Go 1。18 中的標準庫，不要在 1。18 的標準庫中使用泛型。

然而前幾日，Russ Cox（Go 核心開發團隊技術 leader，下簡稱“rsc”）公開發布郵件，稱如果沒有意外情況，Go 1。18 將會支援泛型。

rsc 表示，泛型是 Go 1 釋出以來 Go 語言最重要的變化，同時也是有史以來最大的單一語言特性變化。他寫這封郵件主要是解釋為 Go 加入泛型對 Go 開發團隊以及其他開發者的意義。

rsc 認為，Go 的任何新特性——無論是庫或者語法，都具有不確定性。同樣的，泛型也無法避免這種不確定性。而且由於泛型是一個較大的新特性，因此它帶來的不確定性也會相應地更大。雖然他們為 Go 語言帶來了泛型，但他們自己並不瞭解使用泛型的最佳實踐是什麼，所以無法在文件給出關於何時使用泛型以及何時不使用的準確、明確答案。

此外，Go 團隊沒有任何在生產環境使用泛型的經驗，因此 rsc 表示他們會在釋出說明中明確指出，在生產環境中使用泛型應該適當地謹慎處理。

rsc 強調了 Go 1。18 與其他 Go 1。x 版本一樣具有向後相容的承諾：他們不會破壞使用 Go 1。18 構建的程式碼的相容性，包括使用泛型的程式碼。最壞的情況下，如果發現 Go 1。18 語義存在致命的問題，並需要進行更改（例如在 Go 1。19 中提供更改），他們會使用 go。mod 檔案的 go line 來確定該模組中的原始檔符合 Go 1。18 還是 Go 1。19+ 語義（預計不需要使用這種方法）。

rsc 還提到，第三方工具可能不會在 Go 1。18 釋出時就完全支援泛型。他們正在與許多工具的作者溝通，儘量確保他們儘快更新，但每項工具都有自己的時間安排表。

對於“為什麼不把「泛型」作為可選項提供”的疑問，rsc 也進行了解釋。他表示，在這方面，減少不確定性的唯一方法是預設提供泛型。rsc 用 vendoring 舉例，他表示，當 Go 團隊在 Go 1。5 將 vendoring 作為可選項提供時，發生的情況是幾乎沒有人真正使用它，直到 Go 1。6 預設啟用。另一方面，Go 1。5 版本將 Go 生態分裂成“在標準 Go 下執行的程式碼”和“在啟用 Vendoring 後 Go 執行的程式碼”。現在他們希望儘可能避免泛型也出現這種情況。

對於 Go 1。18 將會支援泛型，引起了網友們的熱烈討論：

你期待支援泛型的 Go 1。18嗎？你是否也認為強型別不能沒有泛型呢？留言區等你！

END