Go ブログ
Go 1.15 の提案
ステータス
すべてが順調に進むと仮定して、2月リリース予定の Go 1.14 リリースが近づいており、RC1候補はほぼ準備が整っています。「Go 2、いよいよ登場！」ブログ記事で概説されているプロセスに従い、次のリリースである今年8月予定の Go 1.15 に含める可能性のある言語またはライブラリの変更について検討する時期が再び来ています。
Go の主な目標は、パッケージとバージョン管理、より優れたエラー処理サポート、およびジェネリクスです。モジュールサポートは順調に進んでおり、日々改善されており、ジェネリクスについても進捗があります (これについては今年後半に詳しく説明します)。7か月前のエラー処理メカニズムを改善しようとしたtry提案は、支持を得ましたが、強い反対もあり、中止することにしました。その後、多くのフォローアップ提案がありましたが、いずれもtry提案よりも説得力がある、明らかに優れている、または同様の論争を引き起こす可能性が低いとは思えませんでした。したがって、現在のところ、エラー処理の変更は追求していません。将来、何らかの洞察が現状を改善するのに役立つかもしれません。
提案
モジュールとジェネリクスが積極的に取り組まれており、エラー処理の変更が当面の間保留されていることを考えると、他に追求すべき変更はあるでしょうか? 列挙型やイミュータブル型のリクエストなど、長年の人気のあるものもありますが、これらのアイデアはいずれもまだ十分に開発されておらず、特に言語変更に伴うコストを考慮すると、Go チームが多くの注意を払うほどの緊急性もありません。
実現可能なすべての提案を検討した結果、そしてさらに重要なことに、長期的な計画なしに新しい機能を段階的に追加したくないため、今回は大きな変更を保留するのが良いという結論に達しました。代わりに、いくつかの新しい vet チェックと、言語のマイナーな調整に集中します。次の3つの提案を選択しました。
#32479. go vet での string(int) 変換の診断。
次の Go 1.14 リリースでこれを完了する予定でしたが、間に合わなかったため、ここでもう一度取り上げます。string(int) 変換は利便性のために Go の初期に導入されましたが、初心者には混乱を招き (string(10) は "10" ではなく "\n" です)、unicode/utf8 パッケージで変換が利用できるようになった現在ではもはや正当化されません。この変換を削除することは後方互換性のない変更であるため、最初に vet エラーから始めることを提案します。
#4483. go vet での不可能なインターフェース-インターフェース型アサーションの診断。
現在、Go では、x の型と T がインターフェースである型アサーション x.(T) (および対応する型 switch case) が許可されています。ただし、x と T の両方に同じ名前で異なるシグネチャを持つメソッドがある場合、x に割り当てられた値が T を実装することは不可能です。そのような型アサーションは常にランタイムで失敗します (パニックまたは false に評価されます)。これをコンパイル時に認識しているため、コンパイラーがエラーを報告しても構いません。この場合にコンパイラーエラーを報告することは後方互換性のない変更であるため、最初に vet エラーから始めることも提案します。
#28591. 定数文字列とインデックスを使用したインデックス式およびスライス式の定数評価。
現在、定数インデックスまたはインデックスで定数文字列をインデックスまたはスライスすると、それぞれ非定数の byte または string 値が生成されます。ただし、すべてのオペランドが定数の場合、コンパイラーはそのような式を定数評価して、定数 (おそらく型なし) の結果を生成できます。これは完全に後方互換性のある変更であり、仕様とコンパイラーに必要な調整を行うことを提案します。
(訂正：この変更は後方互換性がないことが投稿後に判明しました。詳細はコメントを参照してください。)
タイムライン
これら3つの提案はいずれも物議を醸すものではないと信じていますが、重要な何かを見逃している可能性は常にあります。そのため、提案は Go 1.15 リリースサイクルの開始時 (または Go 1.14 リリース直後) に実装する予定であり、経験を積んでフィードバックを提供するための十分な時間が確保されます。提案評価プロセスに従い、最終決定は開発サイクルの終わり、2020年5月初めに下されます。
もう一つ…
徹底的にレビューできるよりもはるかに多くの言語変更提案 (LanguageChange ラベルの付いた issue) を受け取っています。たとえば、エラー処理だけでも 57 件の issue があり、そのうち 5 件は現在もオープン状態です。言語変更に伴うコストは、どんなに小さくても高く、メリットが不明確なことが多いため、慎重にならざるを得ません。そのため、ほとんどの言語変更提案は遅かれ早かれ却下され、最小限のフィードバックしか得られない場合があります。詳細なアイデアを時間をかけて詳細に説明した場合、すぐに却下されない方が良いでしょう。一方、一般的な提案プロセスは意図的にシンプルであるため、わずかにしか検討されていない言語変更提案を非常に簡単に作成できるため、レビュー委員会に多大な作業が発生します。全員のエクスペリエンスを向上させるために、言語変更に関する新しいアンケートを追加しています。そのテンプレートに記入すると、レビュー担当者は自分で質問に答える必要がないため、提案をより効率的に評価するのに役立ちます。また、提案者には、最初から期待を設定することで、より良いガイダンスを提供できることを願っています。これは、必要に応じて時間をかけて改善する実験です。
Go エクスペリエンスの向上にご協力いただきありがとうございます！
次の記事: pkg.go.dev の次のステップ
前の記事: 2019 年 Go 開発者アンケートの発表
ブログインデックス