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 運行的代碼”。現在他們希望盡可能避免泛型也出現這種情況。