[API Proposal]: IndexOf extension method on IEnumerable<T>

[rjperes]

Background and motivation

As the counterpart to ElementAt(), and Index(), I suggest the creation of an IndexOf() method, which would return the index of the passed element on a list, or -1 if the element is not found. This could even be implemented in LINQ to databases, as there are ways to obtain the index of a row.

API Proposal

namespace System.Collections.Generic;

public static class EnumerableExtensions
{
    public static int IndexOf<T>(this IEnumerable<T> source, T element)
    {
        ArgumentNullException.ThrowIfNull(source);
        //just an idea, but can be made simpler, without needing to traverse the source twice 
        //if source is List<T>, we can just use FindIndex
        return source.Index().Where(elm => elm.Item.Equals(element)).Select(x => x.Index).FirstOrDefault(-1);
    }
}

API Usage

string[] colours = ["red", "green", "blue"];
var greenIndex = colours.IndexOf("green");

Alternative Designs

No response

Risks

No breaking changes, as it's a new method.

[dotnet-policy-service]

Tagging subscribers to this area: @dotnet/area-system-linq
See info in area-owners.md if you want to be subscribed.

[stephentoub]

string[] colours = ["red", "green", "blue"];
var greenIndex = colours.IndexOf("green");

That already works today if you set <LangVersion>preview</LangVersion> in your csproj, as MemoryExtensions.IndexOf then automatically applies to arrays. Plus IList<T> already has an IndexOf. So this would really only be about non-indexible collections. I'd be concerned about exposing something like this for non-indexible enumerables, if for no other reason than there's no guarantee the index will be correct for a second enumeration.

[rjperes]

Right, and how is that different from ElementAt, for non-indexable collections, which already exists?
As for the method you mentioned, it will work for strings, but not in general for any T.

[stephentoub]

As for the method you mentioned, it will work for strings, but not in general for any T.

It'll work for any T : IEquatable<T>, and #28934 will work for all other T.

and how is that different from ElementAt, for non-indexable collections, which already exists?

ElementAt is problematic, for a variety of reasons, including that the data could change on subsequent enumeration and including that it can easily lead to unexpected O(N^2) evaluation. I don't think we should be doubling-down on it.

[huoyaoyuan]

and how is that different from ElementAt, for non-indexable collections, which already exists?

ElementAt is problematic, for a variety of reasons, including that the data could change on subsequent enumeration and including that it can easily lead to unexpected O(N^2) evaluation. I don't think we should be doubling-down on it.

ElementAt can be effectively considered as Skip(n).Take(1), which is a one-shot usage of the enumerable in case you do need only one element.

For IndexOf, the index is much less usable without consuming the enumerable again.

Plus IList<T> already has an IndexOf. So this would really only be about non-indexible collections.

How about IReadOnlyList<T>? It doesn't provide lookup because of covariance.

[eiriktsarpalis]

Agree that we shouldn't be exposing this due to the index not being practical to use with arbitrary enumerables.

[julealgon]

Agree that we shouldn't be exposing this due to the index not being practical to use with arbitrary enumerables.

@eiriktsarpalis what if you just want to know the position at that point in time for some other purpose, and you don't intend to try to use it to index back into the enumerable?

[eiriktsarpalis]

Can you share an example where this might be the case? Is it common enough to warrant inclusion in System.Linq and not be a helper when necessary?

[julealgon]

Can you share an example where this might be the case?

To be honest I can't of the top of my head, no. I was playing devil's advocate on this one.

Is it common enough to warrant inclusion in System.Linq and not be a helper when necessary?

Fair point. It is probably not common enough. I really can't say as I personally never had the need for it.

My argument was solely on the reasoning that "because you can't reliably index back into the IEnumerable with the value, it is not a good idea". I still think that particular argument is somewhat weak as it assumes that the only ever need for the index is to index back into the original collection.

[rjperes]

“ My argument was solely on the reasoning that "because you can't reliably index back into the IEnumerable with the value, it is not a good idea"

Of course, this is an argument against ElementAt.
The implementation I proposed could of course be different, but this would be an O(N), and I think would be a good companion to Index and ElementAt, which would work for any kind of T, not just those that implement some interface. Also, a similar method over IQueryable could also come in handy. But if you guys think that it’s inappropriate, then just close it.

[eiriktsarpalis]

I still think that particular argument is somewhat weak as it assumes that the only ever need for the index is to index back into the original collection.

That may be true, but at the same we wouldn't want to consider an API unless there is evidence of it being impactful.

[rjperes]

Fair enough. Like all LINQ methods, this can be easily achieved, so if you don’t think this in relevant, then by all means close it.

[eiriktsarpalis]

Sounds good. We can always revisit the proposal if we have more evidence of this being impactful enough for inclusion.