Go 部落格
Go 1.15 提案
狀態
我們接近預計在二月發行的 Go 1.14，假設一切順利，候選版 RC1 幾乎已經準備好了。根據 Go 2, here we come! 部落格文章中概述的流程，在我們的開發和發行週期中，再次該考慮我們是否要納入下一個版本（預計於今年八月發行的 Go 1.15）中有哪些想要納入的語言或函式庫變更。
Go 的首要目標仍然是套件和版本的管理、更好的錯誤處理支援以及泛型。模組支援狀況良好且每日進步當中，我們也正在泛型前線持續前進（稍後將說明）。七個月前我們嘗試提供更佳的錯誤處理機制，即 try 提案，已獲得不錯的支持，但也有極大的反對聲音，我們決定放棄。在提案提交之後，出現許多後續提案，但沒有任何提案看起來令人信服、顯然比 try 提案更為出色、或較不可能引發類似的爭論。因此，我們現在不再進一步修正錯誤處理。或許 framtirs 的一些見解，有助於我們改善現狀。
提案
考量到模組和泛型正積極開發中，而且現在錯誤處理變更已暫停，我們應持續進行哪些變更（如果有）？有一些長久以來的熱門項目，例如列舉型別和不可變型別的要求，但沒有任何一個已經完善到足夠的程度，它們也還不至於迫切到值得由 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)（以及對應的類型交換案例），其中 x 與 T 的類型為介面。但是，如果 x 與 T 皆具有具有相同名稱但簽章不同的方法，則配置給 x 的任何值不可能也實作 T；在執行時間，此類型的斷言始終會失敗（發生恐慌或評估為 false）。由於我們在編譯時間知道這一點，編譯器也可以回報錯誤。在這種情況下回報編譯錯誤並非向後相容的變更，因此我們也建議先從 vet 錯誤開始。
#28591. 使用常數字串和索引評估常數索引和切片運算式。
目前，使用常數索引或常數索引來編制常數字串的索引或切片會分別產生非常數位元組或字串值。但是，如果所有運算元都是常數，編譯器可以常數評估此類運算式並產生常數（可能未分型的）結果。這是一個完全向後相容的變更，我們建議對規格和編譯器進行必要的調整。
（更正：我們在張貼後發現此變更並非向後相容；有關詳細資訊，請參閱意見。）
時間軸
我們相信這三個提案並無爭議，但總有可能我們遺漏了一些重要事項。由於這個原因，我們計畫在 Go 1.15 發行週期的初期（在 Go 1.14 發行時或稍後）實作這些提案，以便有充足時間收集經驗並提供回饋。根據提案評估流程，最終決定將在開發週期結束時，亦即 2020 年 5 月初做出。
還有另一件事...
我們收到的語言變更提案（標籤為 LanguageChange 的議題）遠多於我們能仔細審查的數量。舉例來說，單單是錯誤處理就有 57 個議題，其中有 5 個目前仍為開啟狀態。因為進行語言變更的成本很高，無論變更幅度大小，且好處經常不明確，因此我們必須謹慎行事。因此，大多數語言變更提案最後都會遭到拒絕，有時甚至只會收到最少量的回饋。這種情況對所有相關者而言都不滿意。如果您花費大量時間和精力將自己的想法仔細規劃好，您一定不希望它馬上就被拒絕。另一方面，因為一般的 提案程序 故意設計得很簡單，所以撰寫語言變更提案，要花費的心血更是少之又少，這會造成審查委員會大量的工作。為了改善大家的體驗，我們新增了一份 問卷 給語言變更相關事項：填寫該範本有助於審查者更有效率地評量提案，因為他們不需要自己嘗試回答那些問題。而它也能提供更好的提案指南，讓提案者從一開始就能設定正確的期望。這是一個我們將視需要逐步改善的實驗。
感謝您協助我們改善 Go 體驗！
下一篇文章： pkg.go.dev 的下一步行動
上一篇文章： 宣布 2019 年 Go 開發人員調查
部落格索引