The Go Blog（Goブログ）
Go 2へ向けての次のステップ
現状
Go 1.13のリリースに向けて順調に進んでおり、今年の8月上旬にリリースされる予定です。これは、言語の変更に関する長期のモラトリアムの後、言語に具体的な変更（仕様のマイナーな調整だけでなく）が含まれる最初のリリースです。
これらの言語変更に至るために、「Go 2、いよいよ登場！」ブログ記事で概説されている新しい提案評価プロセスに従い、Go 2の提案のより大きなリストから選択された、実行可能な提案の小さなセットから始めました。最初の提案の選択は、比較的マイナーで、ほとんど議論の余地がないものにし、プロセスを順調に進める可能性を高くしたいと考えました。モジュール固有の言語バージョン選択を最終的に可能にするモジュールがまだデフォルトのビルドモードではないため、提案された変更は、混乱を最小限に抑えるために後方互換性が必要でした。要するに、この最初の変更ラウンドは、大きな問題に取り組むというよりも、再びボールを転がし、新しいプロセスで経験を積むことでした。
当初の提案リスト - 一般的なUnicode識別子、2進整数リテラル、数値リテラルの区切り文字、符号付き整数シフトカウント - は、削減と拡張の両方を行いました。一般的なUnicode識別子は、具体的な設計ドキュメントが時間内に用意できなかったため、採用されませんでした。2進整数リテラルの提案は大幅に拡張され、Goの数値リテラル構文の包括的な見直しと近代化につながりました。また、エラー検査に関するGo 2ドラフト設計提案を追加しました。これは部分的に承認されています。
Go 1.13でこれらの初期変更が行われたので、Go 1.14に目を向け、次に何に取り組むべきかを決定する時が来ました。
Go 1.14の提案
今日のGoの目標は2007年と同じです。ソフトウェア開発の規模を拡大することです。Goのスケーラビリティ向上への道のりで3つの最大のハードルは、パッケージとバージョン管理、より優れたエラー処理サポート、そしてジェネリクスです。
Goモジュールサポートがますます強化されるにつれて、パッケージとバージョン管理のサポートに対処しています。これにより、より優れたエラー処理サポートとジェネリクスが残ります。私たちはこれらの両方に取り組んでおり、デンバーで開催された昨年のGopherConでドラフト設計を発表しました。それ以来、これらの設計を繰り返し検討してきました。エラー処理については、具体的で、大幅に改訂および簡素化された提案を公開しました（下記参照）。ジェネリクスについては、サンディエゴで開催される今年のGopherConで講演（Ian Lance Taylorによる「Goのジェネリクス」）が予定されていますが、まだ具体的な提案段階には達していません。
また、言語への小規模な改善を続けたいと考えています。Go 1.14では、以下の提案を選択しました
#32437。組み込みのGoエラーチェック関数「try」（設計ドキュメント）。
これは、エラー処理の改善に関する具体的な提案です。提案された、完全に後方互換性のある言語拡張は最小限ですが、エラー処理コードに大きな影響を与えることが期待されます。この提案はすでに膨大な数のコメントを集めており、フォローアップするのは簡単ではありません。簡単な概要については、最初のコメントから始めて、詳細な設計ドキュメントを読むことをお勧めします。最初のコメントには、これまでのフィードバックの概要につながるいくつかのリンクが含まれています。投稿する前に、フィードバックの推奨事項（以下の「次のステップ」セクションを参照）に従ってください。
#6977。重複するインターフェースの埋め込みを許可する（設計ドキュメント）。
これは、インターフェースの埋め込みをより寛容にするための、古く、後方互換性のある提案です。
#32479 go vetでstring(int)変換を診断する。
string(int)変換は、便宜上Goの初期に導入されましたが、初心者にはわかりにくく（string(10)は"10"ではなく"\n"です）、unicode/utf8パッケージで変換が利用できるようになった今では正当化されません。この変換の削除は後方互換性のない変更であるため、代わりにvetエラーから始めることを提案します。
これは、暗号ライブラリのために採用したい一連の設計原則に関するフィードバックのリクエストです。crypto/tlsからSSLv3サポートを削除する関連提案も参照してください。
次のステップ
私たちは、これらすべての提案について積極的にフィードバックを求めています。提案が実際にはうまく機能しない理由、または設計で見落としている可能性のある問題点について説明する、事実に基づいた証拠に特に興味があります。提案を支持する説得力のある例も非常に役立ちます。一方、個人的な意見のみを含むコメントは、行動に移せるものが少なくなります。確認はできますが、建設的な方法で対処することはできません。投稿する前に、詳細な設計ドキュメントと以前のフィードバックまたはフィードバックの概要を読む時間を取ってください。特に長い議論では、あなたの懸念はすでに以前のコメントで提起され、議論されている可能性があります。
特定の提案で実験段階に進むことさえしない強力な理由がない限り、Go 1.14サイクル（2019年8月初め）の開始時にこれらすべてを実装して、実際に評価できるようにする予定です。提案評価プロセスに従い、最終決定は開発サイクルの終わり（2019年11月初め）に行われます。
Goの改善にご協力いただきありがとうございます！
次の記事：新しいGoストアのお知らせ
前の記事：Go 2018アンケート結果
ブログインデックス