変更支持の議論

もちろん、変更を支持する有効な議論もあります：

ユーザー調査のトップの苦情

より良いエラーハンドリングサポートの欠如は、私たちのユーザー調査で依然としてトップの苦情です。Goチームが本当にユーザーフィードバックを真剣に受け止めるなら、最終的にこれについて何かをするべきです。（ただし、言語変更に対する圧倒的な支持があるようにも見えません。）

おそらく文字数を減らすことに単独で焦点を当てるのは見当違いかもしれません。より良いアプローチは、ボイラープレート（err != nil）を削除しながら、キーワードでデフォルトのエラーハンドリングを高度に可視化することかもしれません。

このようなアプローチは、読者（コードレビュアー！）がエラーが処理されていることを「二度見る」ことなく見ることを容易にし、コードの品質と安全性の向上をもたらすかもしれません。これは、checkとhandleの始まりに戻ることになります。

問題が直接的なエラーチェックの構文的冗長性なのか、それとも良いエラーハンドリングの冗長性なのか、すなわち、APIの有用な部分であり、開発者とエンドユーザーの両方にとって意味のあるエラーを構築することなのか、私たちは実際にはよく知りません。これは、より深く研究したいことです。

現在のエラーハンドリングパターンには、改善の余地があるいくつかの領域があります：

エラーハンドリングのための専用構文は、正常なコードパスとエラーパスをより明確に分離できるかもしれません。これにより、コードレビュー時により迅速に理解でき、保守性が向上する可能性があります。

現在のパターンでは、開発者がエラーに適切なコンテキストを追加することを忘れがちです。構文レベルでのサポートにより、より一貫したエラー報告を促進できるかもしれません。

Goを学習している新しい開発者にとって、現在のエラーハンドリングパターンは最初の大きな障壁の一つです。より直感的な構文は、言語の採用を促進する可能性があります。

一部の状況では、現在のパターンがコンパイラの最適化を妨げる可能性があります。専用構文により、より効率的なコード生成が可能になるかもしれません。

これらの議論は、言語の進化と改善への継続的な取り組みの一部として考慮される価値があります。