> Source: https://www.ymotongpoo.com/works/goblog-ja/go2-next-steps/


# Go 2 に向けた次のステップ

[Next steps toward Go 2](https://go.dev/blog/go2-next-steps) by Robert Griesemer, for the Go team

## 現状

Go 1.13のリリースに向けた作業は順調に進んでおり、今年の8月上旬にはリリースできる見込みです。
これは、長らく変更を凍結していた言語仕様に対して、単なる細かな調整ではなく具体的な変更を含む
初めてのリリースとなります。

これらの言語変更にたどり着くまでに、私たちはまず、数多くある[Go 2の提案](https://github.com/golang/go/issues?utf8=%E2%9C%93&q=is%3Aissue+is%3Aopen+label%3AGo2+label%3AProposal)の中から
実現性の高い少数の提案を選び出すところから始めました。これは「[Go 2, here we come!](https://go.dev/blog/go2-here-we-come)」の
ブログ記事で説明した新しい提案評価プロセスに則ったものです。最初に選ぶ提案は比較的小さく、ほとんど異論の出ないものにして、
プロセスを通過する可能性を十分高くしておきたいと考えていました。提案する変更は後方互換性を保ち、影響を最小限に抑える
必要がありました。というのも、いずれはモジュールごとに言語バージョンを選択できるようにする[モジュール](https://go.dev/blog/using-go-modules)が、
まだデフォルトのビルドモードにはなっていないからです。要するに、今回の最初のラウンドの変更は、大きな課題に取り組むという
よりも、物事を再び動かし始め、新しいプロセスについての経験を積むことに主眼を置いたものでした。

私たちの[当初の提案リスト](https://go.dev/blog/go2-here-we-come)([一般的なUnicode識別子](https://go.dev/issue/20706)、
[2進整数リテラル](https://go.dev/issue/19308)、[数値リテラルの区切り文字](https://go.dev/issue/28493)、
[符号付き整数のシフト数](https://go.dev/issue/19113))は、削られたものもあれば、拡張されたものもありました。
一般的なUnicode識別子は、期限までに具体的な設計文書を用意できなかったため見送りとなりました。2進整数リテラルの
提案は大幅に拡張され、[Goの数値リテラル構文](https://go.dev/design/19308-number-literals)を包括的に見直し
刷新することにつながりました。そして、[部分的に受け入れられた](https://go.dev/issue/29934#issuecomment-489682919)
[エラー検査](https://go.dev/design/go2draft-error-inspection)に関するGo 2ドラフト設計提案も追加しました。

Go 1.13に向けたこれらの最初の変更が定まったところで、次はGo 1.14に目を向け、次に取り組むべきことを決める時期に
なりました。

## Go 1.14に向けた提案

今日Goが目指す目標は、2007年当時と変わらず、[ソフトウェア開発をスケールさせる](https://go.dev/blog/toward-go2)ことです。
このスケーラビリティ向上への道のりでGoが抱える3つの最大の障壁は、パッケージとバージョンの管理、
より優れたエラー処理のサポート、そしてジェネリクスです。

Goのモジュールサポートがますます強化されるにつれて、パッケージとバージョンの管理への対応は進んでいます。
残るはより優れたエラー処理のサポートとジェネリクスです。私たちはこの両方に取り組んでおり、昨年デンバーで開催された
GopherConで[ドラフト設計](https://go.dev/design/go2draft)を発表しました。それ以来、それらの設計に反復的な改良を
重ねてきました。エラー処理については、具体的で、大幅に見直され簡素化された提案を公開しました(後述)。ジェネリクスに
ついては、今年サンディエゴで開催されるGopherConでIan Lance Taylorによる講演「Generics in Go」が
[予定されている](https://www.gophercon.com/agenda/session/49028)など進展はありますが、まだ具体的な提案の段階には
達していません。

また、言語に対するより小さな改善も継続していきたいと考えています。Go 1.14に向けて、私たちは次の提案を選びました。

[#32437](https://go.dev/issue/32437)。組み込みのGoエラー検査関数「try」
([設計文書](https://go.dev/design/32437-try-builtin))。

これは、エラー処理を改善するための私たちの具体的な提案です。提案されている言語拡張は完全に後方互換性があり
最小限のものですが、エラー処理コードに対しては大きな影響があると見込んでいます。この提案にはすでに膨大な数の
コメントが寄せられており、追いかけるのは容易ではありません。まずは概要をつかむために
[最初のコメント](https://go.dev/issue/32437#issue-452239211)から読み始め、その後で詳細な設計文書を読むことを
お勧めします。最初のコメントには、これまでのフィードバックの要約につながるいくつかのリンクが含まれています。
投稿する前に、フィードバックについての推奨事項に従ってください。詳しくは後述の「次のステップ」のセクションで
説明します。

[#6977](https://go.dev/issue/6977)。重複するインターフェースの埋め込みを許可する
([設計文書](https://go.dev/design/6977-overlapping-interfaces))。

これは、インターフェースの埋め込みをより寛容にするための、古くからある後方互換性のある提案です。

[#32479](https://go.dev/issue/32479) `go vet` で `string(int)` 変換を診断する。

`string(int)` 変換は、利便性のためにGoの初期に導入されたものですが、初心者を混乱させますし
(`string(10)` は `"10"` ではなく `"\n"` になります)、この変換が `unicode/utf8` パッケージで
利用できるようになった今となっては、もはや正当化できません。この変換を削除することは後方互換性のある変更では
ないため、まずは `vet` のエラーとすることを提案します。

[#32466](https://go.dev/issue/32466) 暗号に関する原則を採用する
([設計文書](https://go.dev/design/cryptography-principles))。

これは、私たちが採用したいと考えている暗号ライブラリのための一連の設計原則についてフィードバックを求めるものです。
関連する提案として、`crypto/tls` からSSLv3のサポートを削除するという[提案](https://go.dev/issue/32716)も
参照してください。

## 次のステップ

私たちはこれらすべての提案について積極的にフィードバックを募っています。特に関心があるのは、ある提案が
実際にはうまく機能しないかもしれない理由を示す事実に基づいた証拠や、設計において私たちが見落としているかもしれない
問題点です。提案を裏付ける説得力のある例も役立ちます。一方で、個人的な意見のみを含むコメントは対応しづらい
ものです。私たちはそれを受け止めることはできますが、建設的な形で対処することはできません。投稿する前に、時間を
かけて詳細な設計文書や、これまでのフィードバックやその要約を読んでください。特に長い議論では、同様の懸念が
すでに以前のコメントで提起され、議論されている場合があります。

ある提案について実験段階にすら進めるべきでないという強い理由がない限り、私たちはこれらすべてを
[Go 1.14サイクル](https://go.dev/wiki/Go-Release-Cycle)の開始時点(2019年8月上旬)で実装し、実際に評価できるように
する予定です。[提案評価プロセス](https://go.dev/blog/go2-here-we-come)に則り、最終的な決定は開発サイクルの
終わり(2019年11月上旬)に行われます。

Goをより良い言語にする手助けをしてくださり、ありがとうございます!

By Robert Griesemer, for the Go team