Go 官方部落格
Go 1.15 提案
狀態
Go 1.14 版本即將釋出，如果一切順利，計劃於 2 月釋出，RC1 候選版本已基本準備就緒。根據 Go 2，我們來了！ 部落格文章中概述的流程，現在又到了我們在開發和釋出週期中考慮是否以及希望為下一個版本 Go 1.15（計劃於今年 8 月釋出）包含哪些語言或庫更改的時候了。
Go 的主要目標仍然是包和版本管理、更好的錯誤處理支援以及泛型。模組支援狀況良好，並且每天都在改進，我們也在泛型方面取得進展（今年晚些時候會有更多介紹）。七個月前，我們嘗試提供更好的錯誤處理機制，即 try 提案，獲得了良好的支援，但也遭到了強烈反對，因此我們決定放棄它。在那之後，有很多後續提案，但沒有一個看起來足夠令人信服，明顯優於 try 提案，或不太可能引起類似的爭議。因此，我們暫時沒有進一步推進錯誤處理的更改。也許未來的某個見解將幫助我們改善現狀。
提案
鑑於模組和泛型正在積極開發中，並且錯誤處理更改暫時擱置，我們還應該尋求哪些其他更改（如果有）？有一些長期以來備受青睞的建議，例如列舉和不可變型別的請求，但這些想法都沒有得到充分的發展，也不夠緊急，不足以引起 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)（以及相應的型別 switch case），其中 x 和 T 的型別都是介面。然而，如果 x 和 T 都有一個同名但簽名不同的方法，那麼賦給 x 的任何值都不可能同時實現 T；這樣的型別斷言在執行時將始終失敗（導致 panic 或求值為 false）。既然我們在編譯時就已知曉這一點，編譯器不妨直接報告錯誤。在這種情況下報告編譯器錯誤不是向後相容的更改，因此我們也建議先從 vet 錯誤開始。
#28591. 對帶有常量字串和索引的索引和切片表示式進行常量求值。
目前，使用常量索引或多個索引對常量字串進行索引或切片，會分別產生非常量 byte 或 string 值。但如果所有運算元都是常量，編譯器可以對這些表示式進行常量求值，併產生一個常量（可能是無型別）結果。這是一個完全向後相容的更改，我們建議對規範和編譯器進行必要的調整。
(更正：釋出後我們發現此更改並非向後相容；詳情請參閱評論。)
時間表
我們認為這三個提案都不存在爭議，但總有可能我們遺漏了重要內容。因此，我們計劃在 Go 1.15 釋出週期開始時（在 Go 1.14 釋出時或釋出後不久）實施這些提案，以便有充足的時間收集經驗和提供反饋。根據提案評估流程，最終決定將在開發週期結束時，即 2020 年 5 月初做出。
還有一件事…
我們收到的語言更改提案（標有 LanguageChange 標籤的 issue）比我們能夠徹底審查的數量要多得多。例如，僅錯誤處理一項，就有 57 個 issue，其中 5 個目前仍然開放。由於進行語言更改的成本很高，無論更改多小，而且好處往往不明確，我們必須小心謹慎。因此，大多數語言更改提案遲早會被拒絕，有時只提供最少的反饋。這對於所有相關方來說都是不滿意的。如果您花費了大量時間和精力詳細闡述您的想法，那麼不立即被拒絕會是件好事。另一方面，由於通用的提案流程故意設計得很簡單，因此很容易建立那些只進行了邊緣探索的語言更改提案，這給審查委員會帶來了大量工作。為了改善每個人的體驗，我們為語言更改添加了一個新的問卷：填寫該模板將幫助審查人員更有效地評估提案，因為他們無需自己嘗試回答這些問題。並且希望它還能透過從一開始就設定預期，為提案者提供更好的指導。這是一項實驗，我們將根據需要隨著時間進行完善。
感謝您幫助我們改進 Go 的使用體驗！
下一篇文章：pkg.go.dev 的下一步
上一篇文章：宣佈 2019 年 Go 開發者調查結果
部落格索引