c# - EqualityComparer<T>.Default isn't clever enough -

i reading source code of equalitycomparer<t>.default , found it's not clever. here example:

enum myenum : int { a, b } equalitycomparer<myenum>.default.equals(myenum.a, myenum.b) //is fast  equalitycomparer<int>.default.equals(0, 1)  enum anotherenum : long { = 1l, b = 2l } //is 8x slower equalitycomparer<long>.default.equals(1l, 2l) 

the reason obvious source code of private method in equalitycomparer.

private static equalitycomparer<t> createcomparer() {     //non-important codes ignored     if (c.isenum && (enum.getunderlyingtype(c) == typeof(int)))     {         return (equalitycomparer<t>) runtimetypehandle.createinstanceforanothergenericparameter((runtimetype) typeof(enumequalitycomparer<int>), c);     }     return new objectequalitycomparer<t>(); } 

we can see equalitycomparer<int>.default,equalitycomparer<myenum>.default , equalitycomparer<long>.default wise comparer equals method looks like:

public static bool equals(int x, int y) {     return x == y;  //or return x.equals(y); here                      //i'm not sure, neither causes boxing }  public static bool equals(myenum x, myenum y) {     return x == y;  //it's impossible use x.equals(y) here                      //because causes boxing } 

the above 2 clever, equalitycomparer<anotherenum>.default unlucky, method can see @ last gets objectequalitycomparer<t>(), equals method looks like:

public static bool equals(anotherenum x, anotherenum y) {     return x.equals(y);   //too bad, equals method system.object                        //and it's not override, boxing here!                        //that's why it's slow } 

i think condition enum.getunderlyingtype(c) == typeof(int) pointless, if underlying type of enum of type int, method can convert default comparer of int enum. why can't enum based on long? it's not hard think? special reason? constructing comparer x == y isn't hard enum, right? why @ last gives slow objectequalitycomparer<t> enums(even works correctly)?

i think there's no compelling reason team responsible add feature. features have implementation cost includes (among others) time document, code , test.

there couple of compelling reasons why particular feature has not been picked on others far (and never make cut imo):

• it applies narrow scenario (comparing enums backed other int, , doing in inner loop)
• there straightforward , discoverable solution if causes problem (write own comparer)