1はIComparableを実装していない内、1はMaxと同様の方法で、この問題をキャッチすることができるように、IComparableを実装するためにTを制約していないのはなぜSystem.ArgumentException: At least one object must implement IComparable.なぜIEnumerable <T> .MaxはTをIComparableに制限しますか？
を取得IEnumerable<T>に.Max()拡張メソッドを呼び出し、オブジェクトの場合実行時ではなくコンパイル時に？
もっと柔軟性があると思います。たとえば、文字列を含むIEnumerable<object>がある場合があります。この場合、ObjectにIComparableが実装されていないにもかかわらず、Max()を非常に安全に呼び出すことができます。
多くの設計上の問題の難しい側面は、堅牢なシステムの痛みと、実行時に機能しなくなる柔軟なシステムの苦痛との負担をどのようにバランスさせるかを決めることです。この特定のケースでは、設計者は堅牢性よりも柔軟性を選択しました。それが確かに議論の余地があるのかどうか、しかしいくつかの選択肢は作られなければならず、どちらの選択肢も完璧ではなかった。 –
@エリック：+1、しかし私はあなたがそれを受け入れることができるように答えを投稿したことを望みます。 –
比較は楽しいです。まず、IComparable<T>またはIComparableのいずれかを選択しますか？現在（Comparer<T>.Defaultを介して）それは両方をサポートしていますが、 "this または"という一般的な制約はありません。
次に、Nullable<T>という問題が発生します。これは比較を「持ち上げた」ので、比較可能かどうかはTに依存します。しかしComparer<T>.Defaultはこれを私たちに対処します（Nullable<T>はIComparableもIComparable<T>も実装していません）。
プラス;ジェネリック制約の伝播を節約します。ライブラリコードでこのような制約があるとすぐに、すべての上流の呼び出しコードにすばやく感染し、それをハードスローグにします。
洞察力のある答え。今は私の+1を取得しますが、私は他の回答を落胆させたくないので、まだ受け入れません。 –
質問を書いているうちに私は答えを考えましたが、それでも依頼する価値はあると思っていました。 –