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 將在今年的聖迭戈 GopherCon 大會上發表題為“Go 中的泛型”的演講，但我們尚未達到具體提案階段。
我們還希望繼續對語言進行一些較小的改進。對於 Go 1.14，我們選擇了以下提案
#32437。一個內建的 Go 錯誤檢查函式，“try” (設計文件)。
這是我們改進錯誤處理的具體提案。儘管提議的、完全向後相容的語言擴充套件是最小的，但我們期望它對錯誤處理程式碼產生巨大的影響。這個提案已經吸引了大量的評論，而且跟進並不容易。我們建議從初始評論開始快速瞭解概要，然後閱讀詳細的設計文件。初始評論包含了一些連結，指向目前為止的反饋摘要。在發帖之前，請遵循反饋建議（參見下文“下一步”部分）。
這是一箇舊的、向後相容的提案，旨在使介面嵌入更加容忍。
#32479 在 go vet 中診斷 string(int) 轉換。
早前在 Go 中引入 string(int) 轉換是為了方便，但這對於新手來說令人困惑（string(10) 是 "\n" 而不是 "10"），並且現在 unicode/utf8 包中提供了這種轉換，因此不再合理。由於移除此轉換並非向後相容的變更，我們建議首先以 vet 錯誤的形式提示。
這是一項徵求對一套我們希望採納的密碼學庫設計原則的反饋請求。另請參閱相關的從 crypto/tls 中移除 SSLv3 支援的提案。
下一步
我們正在積極徵集對所有這些提案的反饋。我們特別關注基於事實的證據，說明為什麼某個提案在實踐中可能效果不佳，或者設計中我們可能遺漏的問題方面。支援提案的令人信服的例子也非常有幫助。另一方面，只包含個人意見的評論可操作性較低：我們可以cknowledged它們，但無法以任何建設性的方式加以解決。在發帖之前，請花時間閱讀詳細的設計文件以及先前的反饋或反饋摘要。尤其是在冗長的討論中，您關心的問題可能已經在之前的評論中提出並討論過了。
除非有充分的理由不讓某個提案進入實驗階段，否則我們計劃在Go 1.14 週期開始時（2019 年 8 月初）實現所有這些提案，以便在實踐中進行評估。根據提案評估流程，最終決定將在開發週期結束時（2019 年 11 月初）做出。
感謝您幫助 Go 成為一門更好的語言！
下一篇文章：宣佈新的 Go 商店
上一篇文章：Go 2018 年度調查結果
部落格索引