背景

GopherCon 2017で、Russ Coxは彼のトーク「The Future of Go」(「ブログ記事」)でGoの次の大きなバージョンについての考察を正式に開始しました。私たちはこの未来の言語を非公式にGo 2と呼んできましたが、今ではそれが一斉に、そして単一のメジャーリリースで到来するのではなく、段階的なステップで到来することを理解しています。それでも、Go 2は、その未来の言語について語る方法を持つためだけに、有用な名称なので、今のところは使い続けましょう。

Go 1とGo 2の大きな違いは、誰がデザインに影響を与え、どのように決定が下されるかです。Go 1は外部からの影響は控えめで、少人数のチームでの取り組みでした。Go 2はよりコミュニティ主導になるでしょう。約10年間の公開を経て、私たちは言語とライブラリについて、当初は知らなかった多くのことを学びました。それはGoコミュニティからのフィードバックがあって初めて可能になったことです。

2015年、私たちは特定の種類のフィードバック、つまり言語とライブラリの変更案を集めるために提案プロセスを導入しました。Goチームのベテランメンバーで構成される委員会が、定期的に提案を審査、分類、決定してきました。これはかなりうまく機能しましたが、そのプロセスの一部として、後方互換性のないすべての提案は単純にGo 2とラベル付けして無視してきました。2017年には、Go 2の全体像を考慮したより包括的な計画を優先し、たとえどんなに小さくても、漸進的な後方互換性のある言語変更を行うのをやめました。

Go 2の提案に基づいて行動する時が来ましたが、これを行うにはまず計画が必要です。

現状

この記事の執筆時点で、「Go 2 proposal」というラベルが付いたオープンな課題が約120件あります。それぞれが、多くの場合、既存のGo 1互換性保証を満たさない、重要なライブラリまたは言語の変更を提案しています。Ian Lance Taylorと私はこれらの提案を検討し、それらを分類しました（Go2Cleanup、NeedsDecisionなど）何があるかを把握し、それらの処理を容易にするためです。また、関連する提案を統合し、Goの範囲外であると明確に思われるもの、またはそれ以外に実行不可能なものを閉じました。

残りの提案から得られたアイデアは、Go 2のライブラリと言語に影響を与える可能性が高いでしょう。2つの主要なテーマが初期段階で浮上しています。それは、より良いエラー処理のサポートと、ジェネリクスです。これらの2つの分野のドラフトデザインは今年のGopherConで発表されており、さらなる探求が必要です。

しかし、残りはどうでしょうか？私たちは、数百万人のGoプログラマと大量のGoコードが存在するという事実に制約されており、エコシステムの分裂を避けるために、これらすべてを維持する必要があります。つまり、多くの変更を加えることはできず、加える変更は慎重に選択する必要があります。進歩を遂げるために、私たちはこれらの重要な潜在的な変更に対して新しい提案評価プロセスを実装しています。

提案評価プロセス

提案評価プロセスの目的は、最終決定を下すために、少数の選択された提案についてフィードバックを収集することです。このプロセスはリリースサイクルとほぼ並行して実行され、以下のステップで構成されます。

1. 提案の選択。Goチームは、最終的な決定を下すことなく、採用を検討する価値があると思われる少数のGo 2の提案を選択します。選択基準の詳細については以下を参照してください。

2. 提案へのフィードバック。Goチームは、選択された提案を列挙した発表を送信します。この発表は、コミュニティに対し、選択された提案を進める暫定的な意図と、それぞれの提案についてフィードバックを収集する意図を説明します。これにより、コミュニティは提案や懸念を表明する機会を得ます。

3. 実装。そのフィードバックに基づいて、提案が実装されます。これらの重要な言語とライブラリの変更の目標は、今後のリリースサイクルの初日に提出できる状態にすることです。

4. 実装フィードバック。開発サイクル中に、Goチームとコミュニティは新機能を試してさらなるフィードバックを収集する機会を得ます。

5. ローンチ決定。3ヶ月の開発サイクルの終わり（リリース前の3ヶ月のリポジトリフリーズ開始時）に、そしてリリースサイクル中に収集された経験とフィードバックに基づいて、Goチームは各変更を出荷するかどうかの最終決定を下します。これにより、その変更が期待される利益をもたらしたか、予期せぬコストを生み出したかを検討する機会が提供されます。出荷されると、変更は言語とライブラリの一部となります。除外された提案は、再検討されるか、完全に却下される可能性があります。

2段階のフィードバックがあるこのプロセスは、提案を却下する方向に偏っており、これにより機能の肥大化が防がれ、言語を小さくきれいに保つのに役立つことを願っています。

Go 2のオープンな提案すべてについてこのプロセスを経ることはできません。単純に数が多すぎます。そこで、選択基準が重要になります。

提案の選択基準

提案は少なくとも

1. 多くの人にとって重要な問題に対処していること,

2. 他のすべての人への影響が最小限であること、そして

3. 明確でよく理解された解決策が伴っていること.

要件1は、私たちが行う変更が可能な限り多くのGo開発者を助けること（彼らのコードをより堅牢に、書きやすく、正確にするなど）を保証する一方で、要件2は、彼らのプログラムを壊したり、その他の混乱を引き起こしたりすることによって、可能な限り少数の開発者を傷つけないように注意することを保証します。経験則として、特定の変更によって傷つける開発者の少なくとも10倍の数の開発者を助けることを目指すべきです。実際のGoの使用に影響を与えない変更は、重大な実装コストに対して純粋なメリットがゼロであり、避けるべきです。

要件3がないと、提案の実装がありません。例えば、ある種のジェネリクスが多くの人にとって重要な問題を解決するかもしれないと私たちは信じていますが、まだ明確でよく理解された解決策がありません。それは問題ありません。つまり、その提案は検討される前に再検討する必要があるということです。

提案

私たちはこれが良い計画であり、私たちに役立つはずだと感じていますが、これが単なる出発点であることを理解することが重要です。このプロセスが使用されるにつれて、それがうまく機能しない方法が発見され、必要に応じてそれを改善するでしょう。重要な部分は、実際に使用してみるまでは、どのように改善すべきかわからないということです。

安全な出発点は、少数の後方互換性のある言語提案から始めることです。長らく言語変更を行っていなかったので、これでそのモードに戻ることができます。また、変更によって既存のコードを壊す心配がなくなるため、完璧な試金石となります。

これらを踏まえ、Go 1.13リリース向けのGo 2提案として、以下の選択を提案します（提案評価プロセスのステップ1）。

1. #20706 Unicode TR31に基づく汎用Unicode識別子：これは、非西洋アルファベットを使用するGoプログラマにとって重要な問題に対処するものであり、他の誰にもほとんど影響を与えないはずです。正規化に関する質問があり、コミュニティからのフィードバックが重要になりますが、その後は実装パスがよく理解されています。識別子エクスポートルールはこれによって影響を受けないことに注意してください。

2. #19308、#28493 2進数リテラルと数値リテラルでの_のサポート：これらは比較的小さな変更ですが、多くのプログラマの間で非常に人気があるようです。「重要な問題」を解決するという閾値には達しないかもしれませんが（これまで16進数はうまく機能してきました）、この点でGoを他のほとんどの言語と同等にし、一部のプログラマの不満点を解消します。2進数リテラルや数値の書式設定に関心のない他の人々への影響は最小限であり、実装はよく理解されています。

3. #19113 符号付き整数をシフトカウントとして許可する：すべての非定数シフトのおよそ38%が（人工的な）uint変換を必要とします（詳細な内訳はイシューを参照してください）。この提案は多くのコードを整理し、シフト式をインデックス式や組み込み関数であるcapおよびlenとより同期させます。主にコードに良い影響を与えるでしょう。実装はよく理解されています。

次のステップ

このブログ投稿をもって、私たちは提案評価プロセスの最初のステップを実行し、2番目のステップを開始しました。これで、Goコミュニティである皆さんが、上記の課題についてフィードバックを提供する番です。

明確で承認的なフィードバックが得られた各提案について、私たちは実装を進めます（プロセスのステップ3）。次のリリースサイクルの初日（暫定的に2019年2月1日）までに変更を実装したいので、今回は2ヶ月間の完全なフィードバック期間（2018年12月、2019年1月）を確保するため、実装を少し早めに開始するかもしれません。

3ヶ月の開発サイクル（2019年2月～5月）の間、選択された機能が実装され、tipで利用可能になり、誰もがそれらを体験する機会を得ます。これにより、フィードバックの別の機会が提供されます（プロセスのステップ4）。

最後に、リポジトリフリーズ（2019年5月1日）直後、Goチームは新機能を永続的に保持するか（Go 1互換性保証に含めるか）、または放棄するか（プロセスの最終ステップ）について最終決定を下します。

（リポジトリフリーズ時に機能が削除される可能性が十分にあるため、実装は、機能がシステムの他の部分を不安定にすることなく無効化できるようにする必要があるでしょう。言語変更の場合、それはすべての機能関連コードが内部フラグで保護されていることを意味するかもしれません。）

このプロセスに従うのは今回が初めてなので、リポジトリフリーズは、プロセスを振り返り、必要であれば調整するための良い機会にもなるでしょう。どうなるか見てみましょう。

評価を楽しんでください！