背景

在 2017 年 GopherCon 大會上，Russ Cox 發表了題為《Go 的未來》（The Future of Go，博文）的演講，正式開啟了對 Go 下一個重大版本的思考。我們將這個未來的語言非正式地稱為 Go 2，儘管我們現在明白它將以增量步驟而非一次性盛大發布的形式到來。儘管如此，Go 2 仍然是一個有用的代號，即使只是為了有一個討論未來語言的方式，所以我們暫時繼續使用它。

Go 1 和 Go 2 之間的一個主要區別在於誰將影響設計以及如何做出決策。Go 1 是一個小型團隊的努力，外部影響有限；Go 2 將更多地由社群驅動。經過近 10 年的實踐，我們對語言和庫有了很多最初未曾想到的瞭解，而這一切都得益於 Go 社群的反饋。

2015 年，我們推出了提案流程，用於收集一種特定的反饋：語言和庫更改的提案。由 Go 核心團隊成員組成的委員會定期審查、分類和決定收到的提案。這進行得很順利，但在該過程中，我們忽略了所有不向後相容的提案，簡單地將它們標記為 Go 2。2017 年，我們還停止了任何形式的增量式向後相容的語言更改，無論多麼微小，而是採取了一個更全面的計劃，其中考慮了 Go 2 的整體藍圖。

現在是時候對 Go 2 的提案採取行動了，但要做到這一點，我們首先需要一個計劃。

狀態

在撰寫本文時，有大約 120 個標記為“Go 2 proposal”的開放問題。其中每個提案都提出了重要的庫或語言更改，其中許多不滿足現有的Go 1 相容性保證。Ian Lance Taylor 和我一直在審查這些提案，並對其進行了分類（Go2Cleanup、NeedsDecision 等），以便了解其內容並更容易地進行處理。我們還合併了相關的提案，並關閉了那些明顯超出 Go 範圍或無法操作的提案。

剩餘提案中的想法很可能會影響 Go 2 的庫和語言。早期出現了兩個主要主題：更好的錯誤處理支援和泛型。今年 GopherCon 大會上釋出了這兩個領域的草案設計，還需要進一步的探索。

但其他提案呢？我們受到限制，因為我們現在有數百萬 Go 程式設計師和大量的 Go 程式碼，我們需要將它們全部帶上，以免我們冒著生態系統分裂的風險。這意味著我們不能做太多更改，並且需要仔細選擇我們將要進行的更改。為了取得進展，我們將為這些重大的潛在更改實施一個新的提案評估流程。

提案評估流程

提案評估流程的目的是收集對少量精選提案的反饋，以便做出最終決定。該流程與釋出週期大致並行執行，幷包含以下步驟：

1. 提案選擇。Go 團隊選擇少量Go 2 提案，這些提案似乎值得考慮接受，但尚未做出最終決定。有關選擇標準，請參見下文。

2. 提案反饋。Go 團隊會發布公告，列出選定的提案。公告向社群解釋了推進選定提案的初步意圖，並徵求對每個提案的反饋。這使社群有機會提出建議和表達擔憂。

3. 實現。基於這些反饋，提案將被實現。這些重大的語言和庫更改的目標是在即將釋出的釋出週期的第一天準備就緒。

4. 實現反饋。在開發週期中，Go 團隊和社群有機會試用新功能並收集進一步的反饋。

5. 釋出決策。在三個月的開發週期結束時（就在開始釋出前的三個月儲存庫凍結之前），基於在開發週期中收集的經驗和反饋，Go 團隊將就是否釋出每項更改做出最終決定。這提供了一個機會來考慮更改是否帶來了預期的好處或產生了任何意外的成本。一旦釋出，這些更改將成為語言和庫的一部分。被排除的提案可能會重新審視，或者可能被永久拒絕。

透過兩輪反饋，此流程傾向於拒絕提案，這有望防止功能蔓延並有助於保持語言的精簡和清晰。

我們無法為每個開放的 Go 2 提案都走這個流程，因為它們的數量實在太多了。這就是選擇標準發揮作用的地方。

提案選擇標準

提案至少必須

1. 解決許多人面臨的重要問題,

2. 對其他人造成最小的影響，並且

3. 提供清晰且易於理解的解決方案.

要求 1 確保我們所做的任何更改都能幫助儘可能多的 Go 開發人員（使他們的程式碼更健壯、更容易編寫、更可能正確等等），而要求 2 確保我們小心地傷害儘可能少的開發人員，無論是透過破壞他們的程式還是引起其他變化。經驗法則：對於給定的更改，我們應該旨在幫助的開發人員數量至少是受傷害的開發人員數量的十倍。不影響實際 Go 使用的更改，其淨收益為零，並且實施成本很高，應避免。

如果沒有要求 3，我們就無法實現提案。例如，我們認為某種形式的泛型可以解決許多人面臨的重要問題，但我們還沒有清晰且易於理解的解決方案。沒關係，這僅僅意味著提案在被考慮之前需要重新審視。

Proposals

我們認為這是一個很好的計劃，應該對我們很有幫助，但重要的是要理解這僅僅是一個起點。隨著流程的實施，我們將發現它在哪些方面未能良好運作，並將根據需要進行改進。關鍵在於，直到我們在實踐中使用它，我們才不知道如何改進它。

一個安全的起點是採用少數向後相容的語言提案。我們很長時間沒有進行語言更改了，所以這有助於我們重新進入那個狀態。此外，這些更改不會讓我們擔心破壞現有程式碼，因此它們可以作為完美的試探性方案。

話雖如此，我們建議為 Go 1.13 版本選擇以下 Go 2 提案（提案評估流程的步驟 1）：

1. #20706 基於 Unicode TR31 的通用 Unicode 識別符號：這解決了使用非西方字母的 Go 程式設計師面臨的一個重要問題，並且對其他人的影響很小甚至沒有。存在一些我們需要回答的規範化問題，社群的反饋在此很重要，但在那之後，實現路徑是明確的。請注意，識別符號匯出規則不會受到影響。

2. #19308, #28493 二進位制整數文字以及支援數字文字中的“_”：這些是相對較小的更改，在許多程式設計師中似乎非常受歡迎。它們可能未能完全達到解決“重要問題”的門檻（十六進位制數字到目前為止一直執行良好），但它們使 Go 在這方面與其他大多數語言保持一致，並緩解了一些程式設計師的痛點。對於那些不關心二進位制整數文字或數字格式的其他人，影響很小，並且實現也是明確的。

3. #19113 允許有符號整數作為移位計數：據估計，所有非常量移位的 38% 需要（人為地）進行 uint 轉換（有關更詳細的細分，請參閱問題）。此提案將清理大量程式碼，使移位表示式與索引表示式以及內建函式 cap 和 len 更好地同步。它將主要對程式碼產生積極影響。實現是明確的。

下一步

透過這篇博文，我們已經執行了第一步，並開始了提案評估流程的第二步。現在，輪到 Go 社群了，請您就上述問題提供反饋。

對於我們收到清晰且贊同反饋的每個提案，我們將繼續推進實現（流程的步驟 3）。因為我們希望在下一個釋出週期的第一天（暫定為 2019 年 2 月 1 日）實現更改，所以我們可能會提前開始實現，以便留出兩個月的完整反饋時間（2018 年 12 月、2019 年 1 月）。

在為期三個月的開發週期（2019 年 2 月至 5 月）中，選定的功能將在 tip 版本中實現並可用，每個人都有機會從中獲得經驗。這提供了另一個反饋機會（流程的步驟 4）。

最後，在儲存庫凍結後不久（2019 年 5 月 1 日），Go 團隊將做出最終決定，是永久保留新功能（並將其包含在 Go 1 相容性保證中），還是放棄它們（流程的最後一步）。

（由於一項功能可能需要在儲存庫凍結時才被移除，因此實現需要能夠停用該功能而不破壞系統的其餘部分。對於語言更改，這可能意味著所有與功能相關的程式碼都由內部標誌保護。）

這將是我們第一次遵循此流程，因此儲存庫凍結也將是反思該流程並根據需要進行調整的好時機。讓我們看看進展如何。

評估愉快！