为什么 IReadOnlyCollection 有 ElementAt 但没有 IndexOf

Question

I am working with a IReadOnlyCollection of objects.

Now I'm a bit surprised, because I can use linq extension method ElementAt() . But I don't have access to IndexOf() .

This to me looks a bit illogical: I can get the element at a given position, but I cannot get the position of that very same element.

Is there a specific reason for it?

I've already read -> How to get the index of an element in an IEnumerable? and I'm not totally happy with the response.

Answer 1

IReadOnlyList<T> has no IndexOf() for no good reason whatsoever .

If you really want to find a reason to mention, then the reason is historical:

Back in the mid-nineties when C# was laid down, people had not quite started to realize the benefits of immutability and readonlyness, so the IList<T> interface that they baked into the language was, unfortunately, mutable.

The right thing would have been to come up with IReadOnlyList<T> as the base interface, and make IList<T> extend it, adding mutation methods only, but that's not what happened.

IReadOnlyList<T> was invented a considerable time after IList<T> , and by that time it was too late to redefine IList<T> and make it extend IReadOnlyList<T> . So, IReadOnlyList<T> was built from scratch.

They could not make IReadOnlyList<T> extend IList<T> , because then it would have inherited the mutation methods, so they based it on IReadOnlyCollection<T> and IEnumerable<T> instead. They added the this[i] indexer, but then they either forgot to add other methods like IndexOf() , or they intentionally omitted them since they can be implemented as extension methods, thus keeping the interface simpler. But they did not provide any such extension methods.

So, here, is an extension method that adds IndexOf() to IReadOnlyList<T> :

using Collections = System.Collections.Generic;

    public static int IndexOf<T>( this Collections.IReadOnlyList<T> self, T elementToFind )
    {
        int i = 0;
        foreach( T element in self )
        {
            if( Equals( element, elementToFind ) )
                return i;
            i++;
        }
        return -1;
    }

Be aware of the fact that this extension method is not as powerful as a method built into the interface would be. For example, if you are implementing a collection which expects an IEqualityComparer<T> as a construction (or otherwise separate) parameter, this extension method will be blissfully unaware of it, and this will of course lead to bugs. (Thanks to Grx70 for pointing this out in the comments.)

Answer 2

IndexOf is a method defined on List , whereas IReadOnlyCollection inherits just IEnumerable .

This is because IEnumerable is just for iterating entities. However an index doesn't apply to this concept, because the order is arbitrary and is not guaranteed to be identical between calls to IEnumerable . Furthermore the interface simply states that you can iterate a collection, whereas List states you can perform adding and removing also.

The ElementAt method sure does exactly this. However I won't use it as it reiterates the whole enumeration to find one single element. Better use First or just a list-based approach.

Anyway the API design seems odd to me as it allows an (inefficient) approach on getting an element at n -th position but does not allow to get the index of an arbitrary element which would be the same inefficient search leading to up to n iterations. I'd agree with Ian on either both (which I wouldn't recommend) or neither.

Answer 3

It is because the IReadOnlyCollection (which implements IEnumerable ) does not necessarily implement indexing , which often required when you want to numerically order a List . IndexOf is from IList .

Think of a collection without index like Dictionary for example, there is no concept of numeric index in Dictionary . In Dictionary , the order is not guaranteed, only one to one relation between key and value. Thus, collection does not necessarily imply numeric indexing.

Another reason is because IEnumerable is not really two ways traffic. Think of it this way: IEnumerable may enumerate the items x times as you specify and find the element at x (that is, ElementAt ), but it cannot efficiently know if any of its element is located in which index (that is, IndexOf ).

But yes, it is still pretty weird even you think it this way as would expect it to have either both ElementAt and IndexOf or none.

Answer 4

IReadOnlyCollection<T> has ElementAt<T>() because it is an extension to IEnumerable<T> , which has that method. ElementAt<T>() iterates over the IEnumerable<T> a specified number of iterations and returns value as that position.

IReadOnlyCollection<T> lacks IndexOf<T>() because, as an IEnumerable<T> , it does not have any specified order and thus the concept of an index does not apply. Nor does IReadOnlyCollection<T> add any concept of order.

I would recommend IReadOnlyList<T> when you want an indexable version of IReadOnlyCollection<T> . This allows you to correctly represent an unchangeable collection of objects with an index.

Answer 5

This could be helpful to someone:

public static int IndexOf<T>(this IReadOnlyList<T> self, Func<T, bool> predicate)
{
    for (int i = 0; i < self.Count; i++)
    {
        if (predicate(self[i]))
            return i;
    }

    return -1;
}