Russ Cox（Go 核心開發(fā)團隊技術(shù) leader，下簡稱"rsc"）公開發(fā)布郵件，稱如果沒有意外情況，Go 1.18 將會支持泛型。
rsc 表示，泛型是 Go 1 發(fā)布以來 Go 語言最重要的變化，同時也是有史以來最大的單一語言特性變化。他寫這封郵件主要是解釋為 Go 加入泛型對 Go 開發(fā)團隊以及其他開發(fā)者的意義。
rsc 認為，Go 的任何新特性——無論是庫或者語法，都具有不確定性。同樣的，泛型也無法避免這種不確定性。而且由于泛型是一個較大的新特性，因此它帶來的不確定性也會相應(yīng)地更大。雖然他們?yōu)?Go 語言帶來了泛型，但他們自己并不了解使用泛型的最佳實踐是什么，所以無法在文檔給出關(guān)于何時使用泛型以及何時不使用的準確、明確答案。
此外，Go 團隊沒有任何在生產(chǎn)環(huán)境使用泛型的經(jīng)驗，因此 rsc 表示他們會在發(fā)布說明中明確指出，在生產(chǎn)環(huán)境中使用泛型應(yīng)該適當?shù)刂斏魈幚怼?/p>
rsc 強調(diào)了 Go 1.18 與其他 Go 1.x 版本一樣具有向后兼容的承諾：他們不會破壞使用 Go 1.18 構(gòu)建的代碼的兼容性，包括使用泛型的代碼。最壞的情況下，如果發(fā)現(xiàn) Go 1.18 語義存在致命的問題，并需要進行更改（例如在 Go 1.19 中提供更改），他們會使用 go.mod 文件的 go line 來確定該模塊中的源文件符合 Go 1.18 還是 Go 1.19+ 語義（預(yù)計不需要使用這種方法）。
rsc 還提到，第三方工具可能不會在 Go 1.18 發(fā)布時就完全支持泛型。他們正在與許多工具的作者溝通，盡量確保他們盡快更新，但每項工具都有自己的時間安排表。
對于“為什么不把「泛型」作為可選項提供”的疑問，rsc 也進行了解釋。他表示，在這方面，減少不確定性的唯一方法是默認提供泛型。rsc 用?vendoring 舉例，他說道，當 Go 團隊在 Go 1.5 將 vendoring 作為可選項提供時，發(fā)生的情況是幾乎沒有人真正使用它，直到 Go 1.6 默認啟用。另一方面，Go 1.5 版本將 Go 生態(tài)分裂成“在標準 Go 下運行的代碼”和“在啟用 Vendoring 后 Go 運行的代碼”?，F(xiàn)在他們希望盡可能避免泛型也出現(xiàn)這種情況。
