The Go Blog
Go 1.15 の提案
現状
Go 1.14 のリリースが目前に迫っています。RC1候補がほぼ準備完了しており、すべてが順調に進めば2月にリリースされる予定です。Go 2 がやってくる！ のブログ記事で述べられているプロセスに従い、今年の8月に予定されている次のリリース Go 1.15 に、どのような言語またはライブラリの変更を含めるかを検討する時期が、再び開発およびリリースサイクルに到来しました。
Go の主要な目標は、引き続きパッケージとバージョン管理、より良いエラー処理のサポート、およびジェネリクスです。モジュールサポートは良好な状態にあり、日々改善されています。ジェネリクスについても進展が見られます（詳細は今年後半に発表します）。7ヶ月前にエラー処理メカニズムを改善しようとした試みである`try` 提案は、多くの支持を得ましたが、強い反対にも遭ったため、断念することにしました。その後、多くの追跡提案がありましたが、そのどれもが `try` 提案よりも明確に優れているか、または同様の論争を引き起こす可能性が低いと思えるほど説得力のあるものではありませんでした。そのため、今のところエラー処理の変更は追求していません。おそらく将来の洞察が、現状を改善するのに役立つでしょう。
提案
モジュールとジェネリクスが積極的に取り組まれており、エラー処理の変更が一時的に棚上げされていることを考えると、他にどのような変更を追求すべきでしょうか。Enumや不変型などの要望は常にありますが、これらのアイデアはまだ十分に開発されていませんし、Go チームが多大な注意を払うほど緊急でもありません。特に言語変更のコストも考慮すると、なおさらです。
すべての実行可能な可能性のある提案を検討した結果、そしてより重要なこととして、長期的な計画なしに新しい機能を段階的に追加したくないため、今回は大きな変更は控えるべきだと結論付けました。代わりに、いくつかの新しい `vet` チェックと、言語へのわずかな調整に集中します。以下の3つの提案を選定しました。
#32479. `go vet` で `string(int)` 変換を診断する。
この変更は次期 Go 1.14 リリースで実現する予定でしたが、間に合わなかったため、再度提案します。`string(int)` 変換は、Go の初期に利便性のために導入されましたが、初心者には混乱を招きます（`string(10)` は `"\n"` であり ` "10"` ではありません）。`unicode/utf8` パッケージで変換が利用できるようになった現在では、もはや正当化されません。この変換を削除することは後方互換性のない変更であるため、代わりに `vet` エラーから始めることを提案します。
#4483. `go vet` で不可能なインターフェース間の型アサーションを診断する。
現在、Go では、`x` と `T` の両方の型がインターフェースである場合、あらゆる型アサーション `x.(T)` (および対応する型スイッチケース) を許可しています。しかし、`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開発者アンケートのお知らせ
ブログインデックス