I must not have been clear about what I meant. What I mean is that, if you do it your way and just implement Select and SelectMany, that's all you get - you don't get any of these 143 methods [1] for free.

Higher-kinded type support would improve the ability to abstract over these kinds of things and allow API designers to get more for free without repeating oneself time and time again.

[1] https://msdn.microsoft.com/en-us/library/9eekhta0(v=vs.110)....

> What I mean is that, if you do it your way and just implement Select and SelectMany, that's all you get - you don't get any of these 143 methods [1] for fre

I agree with your initial statement about LINQ, it is indeed true that implementing Select only allows your type to work with the LINQ grammar, it doesn't magically make an instance of a functor type-class.

But I do disagree that implementing Select and SelectMany should by default give you access to the 143 methods. For example Aggregate (Fold) can't be implemented in terms of Select and SelectMany. There should be a Foldable type-class (interface), a Monad type-class, a Functor type-class, etc. And if you want your new type (say Option) to be a member of those type-classes then you should provide an instance (like Haskell) that implements the interface of the type-class.

That's what I'm in the process of doing with the language-ext project, because it is possible (and I guess even MS missed that opportunity when they developed LINQ, because it seems that not only is it possible, it is fast and efficient with no special rules in the compiler for Select, SelectMany, Where).

> But I do disagree that implementing Select and SelectMany should by default give you access to the 143 methods.

We both agree on that. ("GetEnumerator" in IEnumerable is what makes all that possible.)