Go 部落格
Go 2 的後續步驟
狀態
我們正穩步邁向 Go 1.13 的釋出，預計將在今年 8 月初。這是第一個包含語言具體更改（而非僅僅是規範的細微調整）的發行版，此前曾有一個較長的此類更改的暫停期。
為了實現這些語言更改，我們從一小部分可行的提案開始，這些提案是從大量 Go 2 提案 中選出的，遵循“Go 2，我們來了！”博文中概述的新提案評估流程。我們希望我們最初選擇的提案相對較小且大部分沒有爭議，這樣它們才有比較大的機會透過該流程。提出的更改必須向後相容，以儘量減少干擾，因為 模組（最終將允許按模組選擇語言版本）尚未成為預設的構建模式。總之，這一輪初始更改更多是為了重新啟動並積累新流程的經驗，而不是解決大問題。
我們的 原始提案列表——通用 Unicode 識別符號、二進位制整數文字、數字文字分隔符、帶符號整數移位計數——經過了刪減和擴充套件。由於我們沒有及時準備好具體的，設計文件，通用 Unicode 識別符號未能入選。二進位制整數文字的提案得到了顯著擴充套件，並導致了對 Go 數字文字語法 的全面審查和現代化。我們還添加了關於 錯誤檢查 的 Go 2 草案設計提案，該提案已 部分接受。
隨著這些針對 Go 1.13 的初步更改到位，現在是時候著眼於 Go 1.14 並確定我們接下來要解決什麼了。
Go 1.14 的提案
我們今天對 Go 的目標與 2007 年相同：擴充套件軟體開發規模。Go 在提高可伸縮性方面最大的三個障礙是包和版本管理、更好的錯誤處理支援以及泛型。
隨著 Go 模組支援越來越強大，包和版本管理的支援正在得到解決。這使得更好的錯誤處理支援和泛型成為焦點。我們一直在研究這兩者，並在去年的丹佛 GopherCon 大會上展示了 草案設計。從那時起，我們一直在迭代這些設計。對於錯誤處理，我們釋出了一個具體、大幅修改和簡化的提案（見下文）。對於泛型，我們正在取得進展，Ian Lance Taylor 的演講“Go 中的泛型”將在今年的聖迭戈 GopherCon 大會上 舉行，但我們尚未進入具體的提案階段。
我們還希望繼續對語言進行小型改進。對於 Go 1.14，我們選擇了以下提案：
#32437。內建的 Go 錯誤檢查函式，“try”（設計文件）。
這是我們為改進錯誤處理而提出的具體提案。雖然提出的、完全向後相容的語言擴充套件很小，但我們預計它將對錯誤處理程式碼產生巨大的影響。該提案已經吸引了大量的評論，並且不容易跟蹤。我們建議從 第一個評論 開始快速瞭解概況，然後閱讀詳細的設計文件。第一個評論包含幾個連結，指向到目前為止的反饋摘要。在釋出之前，請遵循反饋建議（見下文的“後續步驟”部分）。
這是一個古老的、向後相容的提案，旨在使介面嵌入更加容忍。
#32479 在 go vet 中診斷 string(int) 轉換。
string(int) 轉換在 Go 的早期版本中為了方便而引入，但它會讓新使用者感到困惑（string(10) 是 "\n" 而不是 "10"），而且現在 unicode/utf8 包中提供了此轉換，它已經不再合理。由於刪除此轉換不是向後相容的更改，我們建議首先將其作為 vet 錯誤。
這是對我們希望採用的一組加密庫設計原則的反饋請求。另請參閱相關的 從 crypto/tls 中移除 SSLv3 支援的提案。
下一步
我們正在積極徵求對所有這些提案的反饋。我們特別感興趣的是基於事實的證據，說明某個提案在實踐中可能無法很好地工作，或者我們可能在設計中遺漏了什麼問題。支援某個提案的有說服力的例子也非常有幫助。另一方面，僅包含個人意見的評論可操作性較差：我們可以承認它們，但無法以任何建設性的方式解決它們。在釋出之前，請花時間閱讀詳細的設計文件和先前的反饋或反饋摘要。尤其是在長討論中，您的擔憂可能已經在之前的評論中被提出和討論過。
除非有強烈的理由反對將某個提案推入實驗階段，否則我們計劃在 Go 1.14 週期（2019 年 8 月初）開始時實現所有這些提案，以便它們可以在實踐中進行評估。根據 提案評估流程，最終決定將在開發週期結束時（2019 年 11 月初）做出。
感謝您幫助使 Go 成為一個更好的語言！
下一篇文章：宣佈新的 Go Store
上一篇文章：Go 2018 調查結果
部落格索引