原文:https://blog.golang.org/go2-n...golang
現狀ide
不出意外的話,咱們將會在2019年8月發佈Go 1.13版本。這是第一次對Go語言進行很實在的改變(而不是規範性的微調),這些改變很早之前就提出來,可是一直拖延着。函數
爲了實現語言的改變,咱們遵守「Go 2, here we come!」
文檔中的評估流程,先從 Go 2 proposals
(Go 2提案列表) 中挑選了一小部分可行的提案。加密
咱們但願咱們最初挑選的提案相對較小,而且幾乎沒有爭議,以便於更大可能性去完成這些變動。這些「變動」的提案必須向後兼容才能最小化對模塊的破壞性,這些模塊容許指定Go語言版本,而不是默認構建方式。簡而言之,做爲第一輪的變革,主要仍是爲了迭代積累經驗,而不是爲了解決重大問題。spa
在原始提案列表中進行了修剪和擴展的提案:設計
通用Unicode標識符general Unicode identifiers
二進制整數文字binary integer literals
數字文本的分隔符separators for number literals
有符號整數移位計數signed integer shift counts
因爲咱們沒有及時制定「通常的Unicode標識符」這個提案的具體的設計文檔,所以咱們沒有對它進行修整。「二進制整數文字」的提案獲得了顯着擴展,並對Go的數字文本語法進行了全面的改革和現代化。咱們在錯誤檢查中添加了Go 2草案設計方案,該提案已被部分接受。code
通過Go 1.13的這些初步變化以後,如今是時候期待Go 1.14,並肯定咱們接下來要解決哪些問題。blog
Go 1.14的相關提案接口
不忘初心,Go語言目前的目標與2007年相同:使軟件開發規模化。然而「包版本管理」、「錯誤處理機制」和「泛型」這三大問題阻礙了Go語言的發展。圖片
隨着Go module的支持愈來愈強大,咱們解決了包及包版本的管理,因而三大問題中就剩下了「錯誤處理」和「泛型」。
咱們一直在努力解決這兩個問題,並在去年的丹佛GopherCon上展現了草圖設計
draft designs,並一直迭代。
在錯誤處理方面,咱們發佈了一個具體的、通過重大修改和簡化的提案(下文中會提到)。
在泛型方面,咱們還在努力中。在今年的聖地亞哥GopherCon上發表了一篇與之相關的談話
(「Generics in Go」 by Ian Lance Taylor) coming up 可是咱們尚未具體的相關提案。
咱們也但願能繼續完成一些小改進。針對Go1.14版本,咱們挑選瞭如下一些提案:
這是一個改進錯誤處理機制的具體提議。這個提議向後兼容性很弱,可是咱們但願經過這個提議可以大大改善錯誤處理的方式。這個提議已經吸引了大量的意見反饋,所以不太容易跟進。咱們建議從初始評論initial comment 開始,以便於快速瞭解概述,而後再閱讀詳細的設計文檔。這個初始評論initial comment 包括幾個連接,這幾個連接是迄今爲止的反饋的摘要。若是你想提交反饋,在提交以前,請遵照反饋建議(請參閱下面的「後續步驟」部分)
容許嵌套接口是一個老提案,而且是一個向後兼容的提案。
在Go語言早期,爲了方便引入了 string(int) 轉換,然而這種方式很容易讓新手混淆(string(10) 轉換後是"n",而不是"10")而且這種轉換方式在當今unicode/utf8包可用的狀況下不合理。然而,刪除這種轉換會致使不向後兼容,所以咱們提議先使用vet 診斷錯誤。
這是對咱們但願採用的加密庫的一組設計原則的反饋。另請參閱crypto/tls中關於刪除SSLv3 支持的提議.
後續步驟
咱們正在積極徵求關於這些提案的反饋意見。咱們特別想了解的是基於事實的證據,請在反饋中說明爲何提案可能在實踐中不能很好地運做,或者咱們可能在設計中遺漏的問題。
若是支持提案,列舉出使人信服的例子也很是有用。
另外一方面,請不要發佈僅包含針對我的因素的問題:咱們能夠理解,但咱們沒法以任何建設性的方式解決。
在發佈反饋以前,請花點時間認真閱讀詳細的設計文檔和以前的別人提出的反饋或反饋摘要。特別是這些提案在通過了長期討論後,您的關注的問題可能已在早期的評論中提出並進行了討論。
不出意外,咱們計劃在Go 1.14版本中(2019年8月初)開始實施全部這些提案,以便在實踐中對它們進行評估(實踐是檢驗一切的真理)。根據提案評估流程,最終決定將在開發週期結束時(2019年11月初)完成。
感謝您幫助Go成爲更好的語言!