我正在处理 IReadOnlyCollection 的对象。
现在我有点惊讶，因为我可以使用linq扩展方法ElementAt()。但我无权访问IndexOf()。
这在我看来有点不合逻辑：我可以获取给定位置的元素，但无法获取相同元素的位置。
有什么具体原因吗？
我已经阅读了 -> How to get the index of an element in an IEnumerable?，但我对回复并不完全满意。
【问题讨论】：
标签： c# linq extension-methods readonly-collection
IReadOnlyCollection 是一个集合，而不是一个列表，所以严格来说，它甚至不应该有ElementAt()。这个方法在IEnumerable中定义是为了方便，IReadOnlyCollection有它是因为它继承自IEnumerable。如果查看源代码，它会检查IEnumerable 是否实际上是IList，如果是，则返回请求索引处的元素，否则继续对IEnumerable 进行线性遍历，直到请求索引，效率低。
所以，你可能会问为什么IEnumerable 有ElementAt() 而没有IndexOf()，但我觉得这个问题不是很有趣，因为它不应该有这两种方法。 IEnumerable 不应该是可索引的。
现在，一个非常有趣的问题是为什么IReadOnlyList 也没有IndexOf()。
IReadOnlyList<T> 没有 IndexOf() 没有任何理由。如果真要找个理由提，那理由就是历史了：
早在 90 年代中期，当 C# 被淘汰时，人们还没有完全开始意识到不可变性和只读性的好处，所以不幸的是，他们融入语言的 IList<T> 接口是可变的。
正确的做法是提出IReadOnlyList<T> 作为基本接口，并让IList<T> 扩展它，只添加变异方法，但事实并非如此。
IReadOnlyList<T> 是在 IList<T> 之后相当长的一段时间内发明的，到那时重新定义 IList<T> 并使其扩展 IReadOnlyList<T> 为时已晚。所以，IReadOnlyList<T> 是从零开始构建的。
他们不能让IReadOnlyList<T> 扩展IList<T>，因为那样它会继承突变方法，所以他们基于IReadOnlyCollection<T> 和IEnumerable<T> 代替。他们添加了this[i] 索引器，但是他们要么忘记添加其他方法，如IndexOf()，要么故意省略它们，因为它们可以作为扩展方法实现，从而使接口更简单。 但是他们没有提供任何这样的扩展方法。
所以，这里是一个扩展方法，将IndexOf() 添加到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;
}
请注意，此扩展方法不如接口中内置的方法强大。例如，如果您正在实现一个期望 IEqualityComparer<T> 作为构造（或单独的）参数的集合，则此扩展方法将完全不知道它，这当然会导致错误。 （感谢 Grx70 在 cmets 中指出这一点。）
【讨论】：
IReadOnlyList<T> 上缺少int IndexOf(T) 方法没有充分的理由。然而，建议的解决方法存在缺陷，我不同意这种方法不必包含在接口中的说法，因为它可以用扩展方法“替换”。想象一个使用任意IEqualityComparer<T> 的集合，您可能会在此扩展名返回-1 而Contains(T) 返回true（或相反），这可能会导致麻烦。
IEqualityComparer<T> 的重载这一事实吗？您是指它似乎没有使用IEquatable<T> 的事实吗？我可以添加这些，但我认为最好将它们作为练习留给读者。足够先进以实际使用这些接口的程序员会发现这很简单。还有什么吗？
这是因为IReadOnlyCollection（实现IEnumerable）不一定实现indexing，当您想以数字方式订购List时通常需要这样做。 IndexOf 来自 IList。
想想像Dictionary这样没有索引的集合，Dictionary中没有数字索引的概念。在Dictionary中，不保证顺序，key和value之间只有一一对应的关系。因此，集合并不一定意味着数字索引。
另一个原因是因为IEnumerable 并不是真正的双向流量。可以这样想：IEnumerable 可能会在您指定时枚举项目x 并在x（即ElementAt）处找到元素，但它无法有效地知道它的任何元素是否位于哪个索引（即IndexOf）。
但是，是的，即使您以这种方式认为它仍然很奇怪，因为期望它同时具有 either ElementAt 和 IndexOf or none。
【讨论】：
IndexOf 是在List 上定义的方法，而IReadOnlyCollection 仅继承IEnumerable。
这是因为IEnumerable 仅用于迭代实体。然而，索引不适用于这个概念，因为顺序是任意的，并且不能保证在对IEnumerable 的调用之间是相同的。此外，界面只是声明您可以迭代一个集合，而List 声明您也可以执行添加和删除操作。
ElementAt 方法确实可以做到这一点。但是我不会使用它，因为它会重复整个枚举以找到一个元素。最好使用First 或仅使用基于列表的方法。
无论如何，API 设计对我来说似乎很奇怪，因为它允许在第 n 位置获取元素的（低效）方法，但不允许获取任意元素的索引，这将是同样的低效搜索导致多达 n 次迭代。我会同意 Ian 的观点（我不推荐）或两者都不同意。
【讨论】：
IndexOf-method 的狂热并不高。
IReadOnlyCollection<T> 具有 ElementAt<T>()，因为它是 IEnumerable<T> 的扩展，具有该方法。 ElementAt<T>() 迭代 IEnumerable<T> 指定的迭代次数并返回值作为该位置。
IReadOnlyCollection<T> 缺少IndexOf<T>()，因为作为IEnumerable<T>，它没有任何指定的顺序，因此索引的概念不适用。 IReadOnlyCollection<T> 也没有添加任何顺序的概念。
如果您想要IReadOnlyCollection<T> 的可索引版本，我会推荐IReadOnlyList<T>。这允许您正确地表示具有索引的不可更改的对象集合。
【讨论】：
ICollection<T> 也没有IndexOf() 方法，而IList<T> 有方法，让这个看起来更像一个答案。所以这只是语义问题，即集合被视为无序包（可能，但这始终是这些“为什么”问题的问题：谁知道？）。
IReadOnlyList<T> also 没有实现IndexOf() 函数。 IReadOnlyCollection 没有它没什么大不了的，因为它没有索引语义，但使用列表的全部意义在于它应该是有序和可索引的。 List<T> 和 IList<T> 都有，但 IReadOnlyList 没有。这很令人沮丧。
这可能对某人有帮助：
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;
}
【讨论】：