C＃（。NET）の設計上の欠陥[クローズ]

C＃または.NET Framework全般の最大の設計上の欠陥は何ですか？

例：NULL不可の文字列型はなく、IDataReaderから値をフェッチするときにDBNullをチェックする必要があります。

私はこの投稿に強く同意します（ToStringがないことをうんちする人のために、クラスにカスタム形式を提供するデバッガー属性があります）。

上記のリストに加えて、次の合理的なリクエストも追加します。

1. null許容値型を補完するものとしてのnull許容でない参照型。
2. 構造体の空のコンストラクターのオーバーライドを許可し、
3. ジェネリック型制約が封印されたクラスを指定できるようにし、
4. 私は、制約として使用されるときに任意のコンストラクター署名を要求した別のポスターに同意します。どこT : new(string)、またはどこT : new(string, int)
5. また、空のイベントリストと同時設定の両方でのイベントの修正に関する別のポスターにも同意します（後者は注意が必要ですが）。
6. 演算子は、クラスの静的メソッドとしてではなく（または、少なくとも静的メソッドとしてだけではなく）、拡張メソッドとして定義する必要があります。
7. インターフェイスの静的プロパティとメソッドを許可します（Javaにはこれがありますが、C＃にはありません）。
8. オブジェクト初期化子でイベントの初期化を許可します（現在、フィールドとプロパティのみが許可されています）。
9. 「オブジェクト初期化子」構文がオブジェクトの作成時にのみ使用できるのはなぜですか？いつでも利用できるようにしてみませんか。var e = new Foo(); e { Bar = baz };
10. 二次列挙可能な動作を修正し、
11. すべてのコレクションには、反復のための不変のスナップショットが必要です（つまり、コレクションを変更してもイテレーターが無効になることはありません）。
12. タプルは簡単に追加できますが、「Either<T>」のような効率的な閉じた代数型はそうではないので、閉じた代数型を宣言し、それに徹底的なパターンマッチングを適用する方法が欲しいです（基本的にはビジターパターンのファーストクラスのサポートですが、はるかに効率的）; したがって、列挙型を取得し、徹底的なパターンマッチングのサポートでそれらを拡張し、無効なケースを許可しないでください。
13. 一般的なパターンマッチングのサポートが欲しいのですが、少なくともオブジェクトタイプのテストはサポートしたいと思います。また、ここの別の投稿で提案されているswitch構文も好きです。
14. のSystem.IOようなクラスのStream設計がやや不十分であるという別の投稿に同意します。スローするためにいくつかの実装を必要とするインターフェイスNotSupportedExceptionは、悪い設計です。
15. IListそれよりもはるかに単純なはずです。実際、これは、などの具体的なコレクションインターフェイスの多くに当てはまる可能性がありますICollection。
16. IDictionaryなど、メソッドが多すぎると例外がスローされます。
17. 私は、Javaで利用可能なものよりも優れたチェック済み例外の形式を好みます（これを行う方法については、タイプおよびエフェクトシステムに関する調査を参照してください）。
18. ジェネリックメソッドのオーバーロード解決におけるさまざまな厄介なコーナーケースを修正します。たとえば、2つのオーバーロードされた拡張メソッドを提供してみてください。1つは参照型で動作し、もう1つはnull許容の構造体型で動作し、型推論がどのようにそれを好むかを確認します。
19. INotifyPropertyChangedフィールド名を文字列として受け取る、のようなインターフェイスのフィールド名とメンバー名を安全に反映する方法を提供します。これを行うには、ラムダをaMemberExpressionで取る拡張メソッドを使用します。() => Foo、しかしそれはあまり効率的ではありません、
    • 更新：C＃6.0nameof()は単一メンバー名の演算子を追加しましたが、ジェネリックでは機能しません（nameof(T) == "T"実際の型引数の名前の代わりに：実行する必要がありますtypeof(T).Name））-また、「パス」文字列を取得することもできませんたとえばnameof(this.ComplexProperty.Value) == "Value"、可能なアプリケーションを制限します。
20. インターフェイスで演算子を許可し、すべてのコア番号タイプに実装させIArithmeticます。他の便利な共有オペレータインターフェイスも可能ですが、
21. オブジェクトのフィールド/プロパティを変更するのを難しくするか、少なくとも、不変のフィールドに注釈を付けて、型チェッカーに強制させます（これは、クリスケスのゲッターのみのプロパティとして扱います。難しくはありません）。実際、両方を持つことに意味がないため、フィールドとプロパティをより賢明な方法で統合します。C＃3.0の自動プロパティは、この方向への第一歩ですが、十分に進んでいません。
    • 更新：C＃にはreadonlyキーワードがあり、C＃6.0では読み取り専用の自動プロパティが追加されましたが、不変の型と値に対する真の言語サポートほど厳格ではありません。
22. コンストラクターの宣言を簡素化します。私はF＃のアプローチが好きですが、クラス名の代わりに単に「新しい」を必要とするここの他の投稿は、少なくとも、より良いです、

今のところそれで十分だと思います。これらはすべて、私が先週遭遇した苛立ちです。本当に気をつければ、おそらく何時間も続けることができるでしょう。C＃4.0はすでに名前付き、オプション、デフォルトの引数を追加していますが、これは私が強く承認します。

今、1つの不合理な要求のために：

1. C＃/ CLRが型コンストラクターのポリモーフィズムをサポートできれば、本当に素晴らしいでしょう。ジェネリックよりもジェネリック、

かなりお願いしますか？:-)

• 上のReset()方法IEnumerator<T>は間違いでした（イテレータブロックの場合、言語仕様はこれが例外をスローすることさえ要求します）
• 配列を返すリフレクションメソッドは、エリックの見解では間違いでした
• 配列の共分散は奇妙であり、今もなお奇妙です
  • 更新：.NET 4.0を使用するC＃4.0では、ジェネリックインターフェイス（IEnumerable<out T>およびFunc<in T, out TResult>などList<T>）に共変/反変性のサポートが追加されましたが、具体的な型（など）は追加されていません。
• ApplicationException むしろ不利になりました-それは間違いでしたか？
• 同期されたコレクション-良いアイデアですが、実際には必ずしも役立つとは限りません。通常は同期する必要があります Contains、複数の操作する（、then Add）、個別の操作を同期するコレクションはそれほど有用ではありません。
  • アップデート：タイプSystem.Collections.Concurrent、とはTryAdd、GetOrAdd、TryRemove、などは、.NET Framework 4.0で追加されました-工場出荷時のデリゲートを受け入れる方法は、工場でのみ、キーごとに一度呼び出されます保証するものではありませんが。
• より多くの使用が行われた可能性があります using/lockパターンをかもしれません-おそらく、再利用可能な（拡張可能な？）構文を共有できるようになります。を返しIDisposable、使用することでこれをシミュレートusingできますが、より明確であった可能性があります
• イテレータブロック:(怠惰ではなく）事前に引数をチェックする簡単な方法はありません。確かに、2つの連鎖メソッドを書くことができますが、それは醜いです
• より単純な不変性があればいいでしょう。C＃4.0は少し、十分ではありません
• 「このref-typeパラメーターをnullにすることはできません」のサポートはありません-コントラクト（4.0）はこれをいくらか助けますが。しかし、次のような構文Foo(SqlConnection! connection)（nullチェック/を挿入する）のthrowは良いでしょう（int?などとは対照的です）
  • 更新： これはC＃8.0で修正されています。
• ジェネリックスを使用した演算子およびデフォルト以外のコンストラクターのサポートの欠如。C＃4.0はこれを少し解決しますdynamicます。または、次のように有効にすることもできます
• 宣言されているイテレータ変数 は、foreach展開中にwhileの外。つまり、anon-methods / lambdasは、反復ごとに1つではなく、単一の変数をキャプチャします（スレッド化/非同期などで苦痛）
  • 更新：これはC＃5.0で修正されました。

TextWriterはベースです StreamWriterのクラスです。wtf？

それはいつも私を極端に混乱させます。

小さなC＃petpeev-コンストラクターはC ++ / Java構文を使用して、コンストラクターをクラスと同じ名前にします。

New()またはctor()はるかに良かったでしょう。

そして確かに、coderushなどのツールを使用すると、クラスの名前を変更する際の問題は少なくなりますが、読みやすさのPOVから、New（）は非常に明確になります。

私はあなたができないことを理解していません

ここで、T：new（U）

したがって、ジェネリック型Tにはデフォルト以外のコンストラクターがあることを宣言します。

編集：

私はこれをしたい：

public class A 
{
    public A(string text) 
    {

    }
}


public class Gen<T> where T : new(string text) 
{

}

私がこれに最初に言及したことに本当に驚いています：

ADO.NET型付きデータセットは、null許容型のプロパティとしてnull許容列を公開しません。あなたはこれを書くことができるはずです：

int? i = myRec.Field;
myRec.Field = null;

代わりに、これを書く必要がありますが、これはばかげています。

int? i = (int?)myRec.IsFieldNull() ? (int?)null : myRec.Field;
myRec.SetFieldNull();

これは.NET2.0では厄介でしたが、きちんとしたLINQクエリで上記のようなジゲリーポケリーを使用する必要があるため、さらに厄介です。

生成されたAdd<TableName>Rowメソッドがnull許容型の概念に同様に無意味であることも厄介です。生成されたTableAdapterメソッドはそうではないので、なおさらです。

.NETには、開発チームが「わかりました。もうすぐです。出荷してください」と言ったような気がするものはあまりありません。しかし、これは確かにそうです。

1. 私はStream、StringWriter、StringReader、TextReader、TextWriterクラスの大ファンではありません...何が何であるかは直感的ではありません。
2. IEnumerable.Resetは、イテレータの例外をスローします。データバインド時に常にリセットを呼び出すサードパーティコンポーネントがいくつかあり、これらを使用するには最初にリストにキャストする必要があります。
3. Xmlシリアライザーにはシリアル化されたIDictionary要素が必要です
4. HttpWebRequest＆FTP APIのことをすっかり忘れてしまいました...（ニコラスがこれを思い出させてくれたコメントに感謝します:-)

編集
5.私のもう1つの厄介な点は、System.Reflection.BindingFlagsが、使用するメソッドに応じてどのように異なる用途を持っているかです。たとえばFindFieldsでは、CreateInstanceまたはSetFieldはどういう意味ですか？これは、混乱を招くこの列挙の背後にある意味を過負荷にした場合です。

設計上の欠陥だと言っても過言ではありませんが、VBと同じ方法でラムダ式を推測できれば本当に素晴らしいと思います。

VB：

Dim a = Function(x) x * (x - 1)

C＃

これができればいいのですが：

var a = x => x * (x - 1);

これを行う代わりに：

Func<int, int> a = x => x * (x - 1);

それほど長くはないことはわかっていますが、コードゴルフではすべてのキャラクターが気の毒です！彼らはこれらのプログラミング言語を設計するときにそれを考慮に入れていませんか？:)

1. System.Objectのクラス：

   • EqualsとGetHashCode-すべてのクラスが比較可能またはハッシュ可能であるとは限らないため、インターフェイスに移動する必要があります。IEquatableまたはIComparable（または同様のもの）が思い浮かびます。

   • ToString-すべてのクラスを文字列に変換できるわけではないため、インターフェイスに移動する必要があります。IFormattable（または同様のもの）が思い浮かびます。

2. ICollection.SyncRootのプロパティ：

   • 貧弱なデザインを促進し、外部ロックはほとんどの場合より便利です。

3. ジェネリックは最初からそこにあるべきでした：

   • System.Collectionsの名前空間は、多かれ少なかれ、廃止されたクラスとインタフェースの多くが含まれています。

私を苛立たせるものの1つはPredicate<T> != Func<T, bool>パラドックスです。これらは両方ともタイプのデリゲートT -> boolですが、割り当てとの互換性はありません。

一部の人々（ISV）は、dotNetランタイムを必要としないネイティブ実行可能ファイルを作成するために、ビルド時にマシンコードにコンパイルしてリンクできることを望んでいます。

私たちは権利について多くを知っていますOOテクニックます。デカップリング、コントラクトによるプログラミング、不適切な継承の回避、例外の適切な使用、オープン/クローズドプリンシパル、リスコフの置換可能性など。まだ、.Netフレームワークはベストプラクティスを採用していません。

私にとって、.Netの設計における最大の欠陥は、巨人の肩の上に立っているわけではありません。フレームワークを使用するプログラマーの大衆に、理想的とは言えないプログラミングパラダイムを宣伝する。

MSがこれに注意を払っていれば、ソフトウェアエンジニアリングの世界は、この10年間で品質、安定性、スケーラビリティの面で大きな飛躍を遂げた可能性がありますが、残念ながら、後退しているようです。

C＃のswitchステートメントが好きではありません。

こんなもの欲しい

switch (a) {
  1    : do_something;
  2    : do_something_else;
  3,4  : do_something_different;
  else : do_something_weird; 
}

したがって、これ以上の中断（忘れやすい）や、異なる値をコンマで区切る可能性はありません。

リスナーを明示的にチェックする必要があるC＃のイベント。たまたまそこにいた人に放送するというのがイベントのポイントではなかったのでしょうか。ないのに？

ネストされた/再帰的なイテレータのひどい（そしてほとんどの人にはまったく見えない）O（N ^ 2）の振る舞い。

私は彼らがそれについて知っていることを非常にうんざりしています それを修正する方法をますが、それは包含に値する十分な優先順位を持っているとは見なされていません。

私は常にツリーのような構造で作業しており、このように非常に高価な操作を誤って導入した場合は、そうでなければ賢い人々のコードを修正する必要があります。

「yieldforeach」の利点は、構文が単純で簡単なため、正確でパフォーマンスの高いコードが促進されることです。これは、プラットフォームの長期的な成功のために新しい機能を追加する前に、彼らが目指すべき「成功の落とし穴」です。

一部のクラスはインターフェイスを実装しますが、そのインターフェイスのメソッドの多くは実装しません。たとえば、ArrayはIListを実装しますが、9つのメソッドのうち4つはNotSupportedExceptionhttp ： //msdn.microsoft.com/en-us/library/system.array_membersをスローします。 .aspx

インターフェイスの静的メンバーとネストされたタイプ。

インターフェース部材は、インタフェースに固有のタイプのパラメータ（ある場合に特に有用であるなどenum）。列挙型をインターフェイス型にネストすると便利です。

イベントのひどく危険なデフォルトの性質。サブスクライバーが削除されたためにイベントを呼び出して一貫性のない状態になる可能性があるという事実は、ひどいものです。参照してくださいジョンスキートのとエリックリペットの主題についての詳細読書のための優れた記事。

• null どこにでも。

• const どこにも。

• APIに一貫性がありません。たとえば、配列を変更voidするとリターンが返されますが、に追加するStringBufferと同じミュータブルが返されますStringBuffer。

• コレクションインターフェイスは、不変のデータ構造と互換性がありません。たとえばAdd、inSystem.Collections.Generic.IList<_>は結果を返すことができません。

• 構造型はないのでSystem.Windows.Media.Effects.SamplingMode.Bilinear、単にBilinear。

• IEnumerator不変である必要があるときにクラスによって実装される可変インターフェースstruct。

• 平等との比較が混乱している：あなたは持っているSystem.IComparableし、Equalsしかし、あなたはまた、持っているSystem.IComparable<_>、System.IEquatable、System.Collections.IComparer、System.Collections.IStructuralComparable、System.Collections.IStructuralEquatable、System.Collections.Generic.IComparerとSystem.Collections.Generic.IEqualityComparer。

• タプルは構造体である必要がありますが、構造体は末尾呼び出しの除去を不必要に禁止するため、最も一般的で基本的なデータ型の1つが不必要に割り当てられ、スケーラブルな並列処理が破壊されます。

列挙型として0月明かり

列挙型の特性： http //blogs.msdn.com/abhinaba/archive/2007/01/09/more-peculiarites-of-enum.aspx

この良い例で示されているように： http //plus.kaist.ac.kr/~shoh/postgresql/Npgsql/apidocs/Npgsql.NpgsqlParameterCollection.Add_overload_3.html

私の提案では、「@」記号を有効に活用してください。

の代わりに：

if（（myVar＆MyEnumName.ColorRed）！= 0）

これを使って：

if（（myVar＆MyEnumName.ColorRed）！= @ 0）

すでに他の人が作った良い点の長いリストに追加するには：

• DateTime.Now == DateTime.Now すべてではありませんが、ほとんどの場合。

• String不変であるものには、構築と操作のための多くのオプションがありますが、StringBuilder（可変である）にはありません。

• Monitor.Enterそして、Monitor.Exitインスタンスメソッドである必要があったので、ロックするために特定のオブジェクトを新しくする代わりに、を新しくしMonitorてロックすることができます。

• デストラクタは、デストラクタと呼ばれるべきではありませんでした。ECMA仕様では、それらをファイナライザーと呼んでいます。これは、C ++の群集にとってはそれほど混乱しませんが、言語仕様では、それらをデストラクタと呼んでいます。

プロパティの使い方がイライラすることがあります。私はそれらをJavaのgetFoo（）およびsetFoo（）メソッドと同等のものと考えるのが好きです。しかし、そうではありません。

場合プロパティ使用上のガイドラインのプロパティは直列化ので、任意の順序で設定することができるはずという状態は、セッター時の検証のため、彼らがしている役に立たない、働くことができます。オブジェクトが無効な状態になるのを防ぎたい背景から来た場合、プロパティは解決策ではありません。時々私は私たちが物事の種類は、私たちがしているものに限られているので、彼らは、公共のメンバーよりも優れているだけでどのように見ることができないはずのプロパティで行うこと。

そのために、私は常に、プロパティ構文を何らかの方法で拡張できることを望んでいました（これは、ここではほとんど大声で考えています。このようなことができればと思います）。次のようなものを想像してみてください。

private string password;

public string Password
{
    // Called when being set by a deserializer or a persistence
    // framework
    deserialize
    {
       // I could put some backward-compat hacks in here. Like
       // weak passwords are grandfathered in without blowing up
       this.password = value;
    }
    get
    {
       if (Thread.CurrentPrincipal.IsInRole("Administrator"))
       {
           return this.password;
       }
       else
       {
           throw new PermissionException();
       }
    }
    set
    {
       if (MeetsPasswordRequirements(value))
       {
           throw new BlahException();
       }
       this.password = value;
    }
    serialize
    {
        return this.password;
    }
}

それが役立つかどうか、またはそれらにアクセスすることがどのように見えるかはわかりません。しかし、プロパティをさらに活用して、getメソッドやsetメソッドのように扱うことができればと思います。

拡張メソッドは素晴らしいですが、ミックスインに関しては、実際のミックスインでよりクリーンに解決できた可能性のある問題を解決するための醜い方法です（ルビーを見て、私が話していることを確認してください）。それらを言語に追加するための本当に良い方法は、ジェネリックを継承に使用できるようにすることでした。これにより、既存のクラスをオブジェクト指向の優れた方法で拡張できます。

public class MyMixin<T> : T
{
    // etc...
}

これは、次のように使用して文字列を拡張できます。

var newMixin = new MyMixin<string>();

メソッドをオーバーライドできるため、拡張メソッドよりもはるかに強力です。たとえば、メソッドをラップして、言語内でAOPのような機能を使用できます。

暴言でごめんなさい:-)

Microsoftはフレームワークの明らかなバグを修正せず、エンドユーザーが修正できるようにフックを提供しません。

また、実行時に.NET実行可能ファイルにバイナリパッチを適用する方法も、ネイティブライブラリにバイナリパッチを適用せずに.NET Frameworkライブラリのプライベートバージョンを指定する方法もありません（ロード呼び出しをインターセプトするため）。ILDASMは再配布できないため、自動化できません。とにかくパッチ。

• null変数で拡張メソッドを呼び出すことができるかどうかは議論の余地があります。

  オブジェクトa = null; a.MyExtMethod（）; //これは呼び出し可能であり、どこかでMyExtMethodが定義されていると想定します

  便利かもしれませんが、null参照の例外トピックについてはあいまいです。

• 1つの命名「欠陥」。System.configuration.dllの「configuration」の「C」は大文字にする必要があります。

• 例外処理。Javaのように例外を強制的にキャッチまたはスローする必要があり、コンパイラはコンパイル時に例外をチェックする必要があります。ユーザーは、ターゲット呼び出し内の例外情報のコメントに依存しないでください。

フレームワークのV1のSqlCommandの.Parameters.Add（）メソッドはひどく設計されていました-値（int）が0のパラメーターを渡した場合、オーバーロードの1つは基本的に機能しません-これにより、作成されましたSqlCommandクラスの.Parameters.AddWithValue（）メソッド。

1. とのサブセットはICollection<T>ありませんIList<T>。少なくとも、共分散の読み取り専用コレクションインターフェイスIListSource<out T>（列挙子、インデクサー、およびカウントを使用）は非常に便利でした。
2. .NETは弱いデリゲートをサポートしていません。回避策はせいぜい不器用であり、リスナー側の回避策は部分的な信頼では不可能です（ReflectionPermissionが必要です）。
3. 一般的なインターフェースの統合は、それが理にかなっていて問題がない場合でも禁止されています。
4. C ++とは異なり、共変戻り型は.NETでは許可されていません
5. 2つの値タイプが等しいかどうかをビット単位で比較することはできません。機能的な「永続的な」データ構造でTransform(Sequence<T>, Func<T,T>)、関数が同じ値を返すか異なる値を返すかをすばやく判断する必要がある関数を作成していました。関数が引数のほとんど/すべてを変更しない場合、出力シーケンスは入力シーケンスからの一部/すべてのメモリを共有できます。値型Tをビット単位で比較する機能がないと、はるかに遅い比較を使用する必要があり、パフォーマンスが大幅に低下します。
6. .NETは、アドホックインターフェイス（GoやRustで提供されるインターフェイスなど）をパフォーマンスの高い方法でサポートできないようです。このようなインターフェイスを使用すると、クラスがそのインターフェイスを明示的に実装していなくてもList<T>、仮想IListSource<U>（T：Uの場合）にキャストできます。この機能を提供するために、少なくとも3つの 異なる ライブラリ（独立して記述）があります（もちろん、パフォーマンスの欠点があります。完全な回避策が可能である場合、それを.NETの欠陥と呼ぶのは公平ではありません）。
7. その他のパフォーマンスの問題：IEnumeratorでは、反復ごとに2つのインターフェイス呼び出しが必要です。プレーンなメソッドポインタ（IntPtrサイズのオープンデリゲート）または値型デリゲート（IntPtr * 2）は使用できません。固定サイズの配列（任意の型T）をクラス内に埋め込むことはできません。ありませんWeakReference<T>（自分で簡単に書くことができますが、内部でキャストを使用します）。
8. 同一のデリゲートタイプが互換性がないと見なされる（暗黙の変換がない）という事実は、場合によっては（Predicate<T>vsなどFunc<T,bool>）私にとって厄介なものでした。.NETでは、独立したDLLのクラスが同じインターフェイスを実装するだけでは不十分であるため、コンポーネント間の疎結合を実現するために、インターフェイスとデリゲートの構造型を設定できればと思うことがよくあります。インターフェイスを定義するDLL。
9. DBNull.Valuenull同じ目的を同じようにうまく果たしたとしても存在します。
10. C＃には?? =演算子がありません。あなたは書く必要がありますvariable = variable ?? value。実際、C＃には、不必要に対称性に欠ける場所がいくつかあります。たとえば、if (x) y(); else z();（中括弧なしで）書くことはできますが、書くことはできませんtry y(); finally z();。
11. スレッドを作成するときに、子スレッドに親スレッドからスレッドローカル値を継承させることはできません。BCLはこれをサポートしていないだけでなく、すべてのスレッドを手動で作成しない限り、自分で実装することはできません。スレッド作成イベントが発生した場合でも、.NETは特定のスレッドの「親」または「子」を通知できません。
12. 異なるデータ型に2つの異なる長さ属性、「長さ」と「カウント」があるという事実は、ささいな迷惑です。
13. 私はWPFの貧弱な設計について永遠に続けることができました...そしてWCF（いくつかのシナリオでは非常に便利ですが）も疣贅でいっぱいです。一般に、BCLの新しいサブライブラリの多くの肥大化、直感的でない、および限られたドキュメントにより、私はそれらを使用することを躊躇します。新しいものの多くは、はるかに単純で、小さく、使いやすく、理解しやすく、疎結合で、文書化が進んでおり、より多くのユースケースに適用でき、より速く、より強く型付けされている可能性があります。
14. プロパティゲッターとセッターの間の不必要な結合にしばしば悩まされます。派生クラスまたは派生インターフェイスでは、基本クラスまたは基本インターフェイスにゲッターしかない場合、単純にセッターを追加することはできません。ゲッターをオーバーライドすると、セッターを定義できなくなります。セッターを仮想として定義することはできませんが、ゲッターを非仮想として定義することはできません。

1.xで私を驚かせたのは、を使用するSystem.Xml.XmlValidatingReaderとき、ValidationEventHandler'sValidationEventArgsは、やのXmlSchemaExceptionようなすべての有用な情報を持つ基礎となる（内部としてマークされた）を公開しないことでした。代わりに、メッセージ文字列プロパティからこれを解析するか、リフレクションを使用してそれを掘り下げることが期待されています。よりサニタイズされたエラーをエンドユーザーに返したい場合は、あまり良くありません。linenumberposition

たとえば、ある列挙型の値を別の列挙型で使用できないのは気に入らないでしょう。

    enum Colors { white, blue, green, red, black, yellow }

    enum SpecialColors { Colors.blue, Colors.red, Colors.Yellow } 

暗黙的に型指定された変数は、IMOの実装が不十分でした。実際にはLinq式を操作する場合にのみ使用する必要があることはわかっていますが、ローカルスコープ外で宣言できないのは面倒です。

MSDNから：

• varは、ローカル変数が同じステートメントで宣言および初期化されている場合にのみ使用できます。変数をnull、メソッドグループ、無名関数に初期化することはできません。
• varは、クラススコープのフィールドでは使用できません。
• varを使用して宣言された変数は、初期化式では使用できません。言い換えると、この式は有効です。inti =（i = 20）; ただし、この式はコンパイル時エラーを生成します。vari =（i = 20）;
• 複数の暗黙的に型指定された変数を同じステートメントで初期化することはできません。
• varという名前の型がスコープ内にある場合、varキーワードはその型名に解決され、暗黙的に型指定されたローカル変数宣言の一部として扱われません。

実装が不十分だと思う理由は、彼らがそれをvarと呼んでいるからですが、それはバリアントになるにはほど遠いです。これは、完全なクラス名を入力する必要がないための単なる省略構文です（Linqで使用する場合を除く）