C# での破壊的変更の今後の扱い (続報)

去年の3月にブログに書いたものの続報。 C# でも限定的に破壊的変更を許していこうかという話だったわけですが、 ちょっと具体化しました。 ある機能を実現するにあたって破壊的変更の原則と進め方についての話をしています。 破壊的変更の候補 C# 13 で導入したい field アクセス(自動プロパティのバッキングフィールドにアクセスするための field キーワード)と、 これまでに破壊的変更を避けるためにちょっと変な設計になっている var (型推論変数宣言)、_ (discard)が検討の対象になっています。 破壊的変更を認める基準 あくまで控えめな破壊的変更で、エンドユーザーに明確なメリットがある 破壊的変更を踏むようなコードは割かしレア 破壊的変更を起こす予定のコードはどういう理由でどこが問題で、どう直せばいいかが明確に示せる 破壊的変更を避けられるよう、完全に自動で、簡単で、堅牢で、

[karuakun]

Fieldというモデルがあるんだよなぁ、キーワードになってほしくない。