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

C# は、進化していくにあたって、破壊的変更を極力起こさないようにかなり気を使っているプログラミング言語です。 細かい話をすると破壊的変更も皆無ではないんですが、 破壊的変更を認める(認めてでも追加したい新機能を実装する)ハードルは結構高めです。 そんな C# ですが、ちょっとそのハードルの基準を緩められないかというような話が出ています。 Dealing with limited breaking changes in C# その後の Design Meeting 議事録 補足: 影響範囲と、影響力の軽減 補足として、 ハードルを緩めるといっても本当にちょっとです。 C# チームは、「GitHub の public リポジトリを検索して、実際に影響を受けたコードを探す」とかやって既存のコードに対する影響を評価してたりするんですが、 これまで: 単体テストとかでわざと変なコードを書いているも

[tattyu]

a<b,c>(d)に比較式としての解釈があるって全然分からんかった。for中のラムダ式の変数キャプチャはまだ前者のまま？あれ気持ち悪いから無くして欲しい。fieldはずっと欲しかった奴だけど名前めちゃくちゃぶつかるわ。。