前段時間，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嗎？你是否也認為強類型不能沒有泛型呢？