Go 部落格
Go 2 的下一個步驟
狀態
我們正朝著發行 Go 1.13 的目標邁進，預計在今年八月初。這是第一個將包含語言具體變更的版本（而非僅對規範進行微小調整），經過一段時間凍結此類變更後。
要達成這些語言變更，我們從一組小型可行提案開始，從根據「Go 2，我們來了！」部落格文章中列出的新的提案評估流程，從一長串 Go 2 提案中選出。我們希望提案的初始選項相對次要且大多沒有爭議，讓它們有相當高的機會通過此流程。所建議的變更必須是向下相容的，而破壞性最小，因為最終允許模組特定語言版本選取的 模組 還不是預設的建置模式。簡而言之，這最初一輪的變更主要是為了讓工作再度繼續，並在新的流程上累積經驗，而不是為了解決重大問題。
我們的 原始提案一覽 - 通用 Unicode 識別字、二進位整數字面、數字字面的分隔符號、有號整數位移計數 - 已同時減少並擴充。我們沒有及時制定具體設計文件，因此通用 Unicode 識別字未能入選。二進位整數字面的提案大幅擴充，促成 Go 數字字面語法的全面翻新和現代化。此外，我們增加了有關 錯誤檢查 的 Go 2 草稿設計提案，已 部分接受。
這些初始變更適用於 Go 1.13，現在該向前探索 Go 1.14，並決定我們下一步要處理的事項。
Go 1.14 的提案
我們對 Go 的現今目標與 2007 年相同：縮放軟體開發。這條道路上最大的三個障礙，包括套件和版本管理，改進的錯誤處理支援，以及泛型。
隨著 Go 模組的支援越來越強大，套件版本管理的支援也已有所規範。這使得更好的錯誤處理支援與泛型成為開發重點。我們一直在構思這兩方面的技術，並在上一年於 دنفر舉辦的 GopherCon 大會上提出了 設計草稿。從那時起，我們便根據草稿不斷進行調整。就錯誤處理而言，我們已發布具體、更動幅度極大且簡化的建議（請參閱下文）。關於泛型，我們已經有了一定的進展，Ian Lance Taylor 規劃在今年於聖地牙哥舉辦的 GopherCon 大會上發表一篇題為「Go 中的泛型」的演說 (即將舉辦），不過我們尚未提出具體的建議。
我們也希望為語言進行較小的改善。在 Go 1.14 中，我們選出了以下建議
#32437. 內建 Go 錯誤檢查函式，「try」 (設計文件).
這項建議是針對改善錯誤處理而提出的具體辦法。雖然所提出的語言延伸十分精簡，而且不影響後向相容性，但我們預期它將大幅影響錯誤處理程式碼。這項建議目前已收到許多評論，而且後續追蹤不容易。我們建議從 初始評論 開始，取得簡要說明，然後再閱讀詳細的設計文件。初始評論內包含幾個連結，可協助您取得目前為止的所有意見回饋摘要。請遵循回饋建議（請見下方的「後續步驟」部分），再上傳您的意見。
這是一項歷史悠久、不影響後向相容性的建議，目的在讓介面封裝更具容錯力。
#32479診斷 string(int) 在 go vet 中的轉換。
當初為了便利，很早就在 Go 中引入了 string(int)，不過它容易讓剛開始接觸的人感到困惑（string(10) 是 "\n"，而不是 "10"），而且現在 unicode/utf8 套件已經有此轉換功能。由於移除這個轉換不是後向相容性的變更，因此我們建議從 vet error 開始。
這是針對我們想要採用的密碼庫設計原則所徵求的回饋。另外請參閱相關的 建議，其中提議移除 crypto/tls 中的 SSLv3 支援。
後續步驟
我們積極希望在所有這些建議徵求意見回饋。我們特別有興趣了解基於實際情況的證據，說明某項建議在實際應用中可能無法順利運作，或者我們在設計時可能忽略的問題。有說服力的實例支援也很有幫助。不過，只有個人意見的評論行動力較低：我們可以承認這些意見，但無法提供任何建設性的建議。請在發表意見前撥冗閱讀詳細的設計文件以及先前的回饋或回饋摘要。特別在討論串很長時，您的疑慮可能在早期的評論中已提出並獲得討論。
除非有充分理由甚至不需要對特定建議進行實驗階段，我們計畫在 Go 1.14 週期 (2019 年 8 月初) 的開始實作這所有內容，以便實際評估。根據 建議評估流程，最終決定將在開發週期結束時做出 (2019 年 11 月初)。
感謝對 Go 成為更佳語言的幫助！
下一篇文章：宣布推出新的 Go 商店
上一篇文章：2018 Go 調查結果
部落格索引