最近の提案：?操作子

2024年の?操作子提案

その時点では良い解決策がなく、エラーハンドリングのための構文変更を数年間追求しませんでした。しかし、コミュニティの多くの人々がインスピレーションを受け、エラーハンドリング提案の安定した流れを受け取りました。多くは互いに非常に似ており、興味深いもの、理解できないもの、実行不可能なものもありました。

拡大する状況を追跡するために、さらに1年後、Ian Lance Taylorが包括的なissueを作成し、エラーハンドリングの改善のために提案された変更の現在の状態を要約しました。関連するフィードバック、議論、記事を収集するためにGo Wikiが作成されました。

エラーハンドリングの冗長性に関する苦情は続き（Go Developer Survey 2024 H1 Resultsを参照）、一連のますます洗練されたGoチーム内部提案の後、Ian Lance Taylorは2024年に「reduce error handling boilerplate using ?」を公開しました。

今回のアイデアは、Rustで実装されている構造、具体的には?操作子から借用することでした。確立された記法を使用する既存のメカニズムに依存し、長年にわたって学んだことを考慮することで、ついに何らかの進歩を遂げることができるはずでした。

// 提案された"?"文を使用したprintSum実装
func printSum(a, b string) error {
    x := strconv.Atoi(a) ?
    y := strconv.Atoi(b) ?
    fmt.Println("result:", x + y)
    return nil
}

初期の反応と期待

?を使用したGoコードを見せられた小規模で非公式なユーザー研究では、参加者の大多数がコードの意味を正しく推測しました。これは、この機能をもう一度試してみるようにさらに説得しました。

変更の影響を確認できるように、Ianは通常のGoコードを提案された新しい構文を使用するコードに変換するツールを作成し、コンパイラでその機能のプロトタイプも作成しました。

提案の運命

残念ながら、他のエラーハンドリングのアイデアと同様に、この新しい提案もすぐにコメントと、しばしば個人的な好みに基づく小さな調整の多くの提案で氾濫しました。Ianは提案を閉じ、コンテンツをディスカッションに移動して会話を促進し、さらなるフィードバックを収集しました。

わずかに修正されたバージョンはもう少し好意的に受け取られましたが、広範囲な支持は依然として得られませんでした。

繰り返されるパターン

多年にわたる試行の後、Goチームによる3つの本格的な提案と文字通り数百もの（！）コミュニティ提案（そのほとんどはテーマのバリエーション）があり、そのすべてが十分な（圧倒的ではなく）支持を集めることに失敗した今、私たちが直面している問題は：どのように進めるべきか？ そもそも進めるべきなのか？という問題です。