Go 部落格
Go 1.15 的提案
狀態
Go 1.14 版本釋出在即，計劃於二月份釋出（一切順利的話），RC1 候選版本已基本準備就緒。根據 “Go 2, here we come!” 博文所述的流程，現在到了我們開發和釋出週期中考慮是否以及將哪些語言或庫更改納入我們下一個版本 Go 1.15 的時候了，該版本計劃於今年八月釋出。
Go 的主要目標仍然是包和版本管理、更好的錯誤處理支援以及泛型。模組支援目前狀況良好，並且與日俱進，我們在泛型方面也取得了進展（稍後會詳細介紹）。七個月前，我們嘗試提供一種更好的錯誤處理機制，即 try 提案，雖然獲得了很好的支援，但也遭到了強烈的反對，我們最終決定放棄它。在此之後，湧現了許多後續提案，但沒有一個提案足夠有說服力，明顯優於 try 提案，或不太可能引起類似的爭議。因此，目前我們暫時沒有進一步推進錯誤處理的更改。也許未來的某個見解能幫助我們改進現狀。
Proposals
鑑於模組和泛型正在積極開發中，並且暫時擱置了錯誤處理的更改，我們還應該追求哪些其他更改（如果有的話）？有一些長年累月的熱門請求，例如列舉型別和不可變型別，但這些想法都還沒有足夠成熟，也沒有緊迫到需要 Go 團隊投入大量精力，尤其是在考慮語言更改的成本時。
在審查了所有潛在可行的提案後，更重要的是，因為我們不想在沒有長期計劃的情況下逐步新增新功能，我們得出結論，這次最好暫時擱置重大更改。取而代之的是，我們將專注於一些新的 vet 檢查和一個對語言的小調整。我們選擇了以下三個提案：
#32479。在 go vet 中診斷 string(int) 轉換。
我們原本計劃在即將釋出的 Go 1.14 版本中完成這項工作，但當時未能如願，所以現在再次提出。string(int) 轉換在 Go 的早期是為了方便而引入的，但對於新手來說（string(10) 是 "\n" 而不是 "10"）很容易混淆，而且現在 unicode/utf8 包中已提供了轉換，因此不再有必要。由於移除此轉換不是一個向後相容的更改，我們建議首先從 vet 錯誤開始。
#4483。在 go vet 中診斷不可能的介面-介面型別斷言。
目前，Go 允許任何型別斷言 x.(T)（以及相應的型別開關 case），其中 x 和 T 的型別都是介面。然而，如果 x 和 T 都有一個同名但簽名不同的方法，那麼任何賦給 x 的值都不可能同時實現 T；此類型別斷言總會在執行時失敗（恐慌或評估為 false）。由於我們可以在編譯時知道這一點，編譯器可以報告一個錯誤。在此情況下報告編譯器錯誤不是一個向後相容的更改，因此我們也建議首先從 vet 錯誤開始。
#28591。使用常量字串和索引常量地求值索引和切片表示式。
目前，使用常量索引或索引對常量字串進行索引或切片，會分別產生一個非常量 byte 或 string 值。但是，如果所有運算元都是常量的，編譯器就可以常量地求值這些表示式併產生一個常量（可能是未型別化的）結果。這是一個完全向後相容的更改，我們建議對規範和編譯器進行必要的調整。
（更正：釋出後我們發現此更改不是向後相容的；有關詳細資訊，請參見 評論。）
時間線
我們認為這三個提案都並非爭議性，但總有可能我們遺漏了什麼重要的事情。因此，我們計劃在 Go 1.15 釋出週期的開始（在 Go 1.14 釋出時或之後不久）實施這些提案，以便有充足的時間收集經驗並提供反饋。根據 提案評估流程，最終決定將在開發週期結束時，即 2020 年 5 月初做出。
還有一件事……
我們收到的語言更改提案（標記為 LanguageChange 的 issue）比我們能徹底審查的要多得多。例如，僅錯誤處理一項，就有 57 個 issue，其中五個目前仍處於開放狀態。由於語言更改的成本很高（無論多麼微小），而收益常常不明確，我們必須謹慎行事。因此，大多數語言更改提案最終都會被拒絕，有時甚至反饋很少。這對於所有相關方來說都是不令人滿意。如果您花費了大量時間和精力詳細闡述您的想法，那麼不希望它被立即拒絕。另一方面，由於通用的 提案流程 非常簡單，很容易建立僅進行了少量探索的語言更改提案，這會給審查委員會帶來大量工作。為了改善每個人的體驗，我們正在為語言更改新增一個新的 問卷：填寫該模板將有助於審閱者更有效地評估提案，因為他們無需自己回答這些問題。並希望它能透過從一開始就設定預期，為提案者提供更好的指導。這是一個我們將根據需要隨時間推移進行改進的實驗。
感謝您幫助我們改進 Go 的體驗！
下一篇文章：pkg.go.dev 的後續步驟
上一篇文章：宣佈 2019 年 Go 開發者調查
部落格索引