Linq 的 Enumerable.Count 方法检查 ICollection<> 但不检查 IReadOnlyCollection<>

Question

背景：

Linq-To-Objects 具有扩展名method Count()（重载不采用谓词）。当然有时当一个方法只需要一个IEnumerable<out T>（做Linq）时，我们真的会传递一个“更丰富”的对象给它，比如ICollection<T>。在这种情况下，实际上迭代整个集合（即获取枚举器并“移动下一个”一大堆时间）以确定计数是浪费的，因为有一个 property ICollection<T>.Count 用于此目的。而这个“捷径”从 Linq 开始就已经在 BCL 中使用了。

现在，自 .NET 4.5（2012 年）以来，还有另一个非常好的界面，即IReadOnlyCollection<out T>。它类似于ICollection<T>，只是它只包含那些返回 T 的成员。出于这个原因，它可以在T ("out T") 中是协变的，就像IEnumerable<out T> 一样，当项目类型可以或多或少地派生时，这真的很好。但是新界面有自己的属性，IReadOnlyCollection<out T>.Count。见别处on SO why these Count properties are distinct (instead of just one property)。

问题：

Linq 的方法Enumerable.Count(this source) 会检查ICollection<T>.Count，但不会检查IReadOnlyCollection<out T>.Count。

鉴于在只读集合上使用 Linq 非常自然和普遍，更改 BCL 以检查两个接口是否是个好主意？我想这需要一个额外的类型检查。

那会是一个突破性的变化吗（鉴于他们没有“记得”从引入新界面的 4.5 版本开始这样做）？

示例代码

运行代码：

    var x = new MyColl();
    if (x.Count() == 1000000000)
    {
    }

    var y = new MyOtherColl();
    if (y.Count() == 1000000000)
    {
    }

其中MyColl 是实现IReadOnlyCollection<> 但不是ICollection<> 的类型，其中MyOtherColl 是实现ICollection<> 的类型。具体来说，我使用了简单/最小的类：

class MyColl : IReadOnlyCollection<Guid>
{
  public int Count
  {
    get
    {
      Console.WriteLine("MyColl.Count called");
      // Just for testing, implementation irrelevant:
      return 0;
    }
  }

  public IEnumerator<Guid> GetEnumerator()
  {
    Console.WriteLine("MyColl.GetEnumerator called");
    // Just for testing, implementation irrelevant:
    return ((IReadOnlyCollection<Guid>)(new Guid[] { })).GetEnumerator();
  }

  System.Collections.IEnumerator System.Collections.IEnumerable.GetEnumerator()
  {
    Console.WriteLine("MyColl.System.Collections.IEnumerable.GetEnumerator called");
    return GetEnumerator();
  }
}
class MyOtherColl : ICollection<Guid>
{
  public int Count
  {
    get
    {
      Console.WriteLine("MyOtherColl.Count called");
      // Just for testing, implementation irrelevant:
      return 0;
    }
  }

  public bool IsReadOnly
  {
    get
    {
      return true;
    }
  }

  public IEnumerator<Guid> GetEnumerator()
  {
    Console.WriteLine("MyOtherColl.GetEnumerator called");
    // Just for testing, implementation irrelevant:
    return ((IReadOnlyCollection<Guid>)(new Guid[] { })).GetEnumerator();
  }

  System.Collections.IEnumerator System.Collections.IEnumerable.GetEnumerator()
  {
    Console.WriteLine("MyOtherColl.System.Collections.IEnumerable.GetEnumerator called");
    return GetEnumerator();
  }

  public bool Contains(Guid item) { throw new NotImplementedException(); }
  public void CopyTo(Guid[] array, int arrayIndex) { throw new NotImplementedException(); }
  public bool Remove(Guid item) { throw new NotSupportedException(); }
  public void Add(Guid item) { throw new NotSupportedException(); }
  public void Clear() { throw new NotSupportedException(); }
}

并得到输出：

MyColl.GetEnumerator 调用
MyOtherCol.Count 调用

从代码运行来看，第一种情况（IReadOnlyCollection<out T>）没有使用“快捷方式”。在 4.5 和 4.5.1 中可以看到相同的结果。

---

更新在用户 supercat 对 Stack Overflow 的其他地方发表评论后。

Linq 当然是在 .NET 3.5 (2008) 中引入的，而 IReadOnlyCollection<> 仅在 .NET 4.5 (2012) 中引入。然而，在这两者之间，在 .NET 4.0 (2010) 中引入了另一个特性，泛型中的协变。正如我上面所说，IEnumerable<out T> 变成了协变接口。但是ICollection<T> 在T 中保持不变（因为它包含像void Add(T item); 这样的成员）。

在 2010 年（.NET 4）中，如果在编译时类型 IEnumerable<Animal> 的源上使用 Linq 的 Count 扩展方法，其中实际的运行时类型例如为 List<Cat>，则其后果是，比如说，这肯定是一个IEnumerable<Cat>，但通过协方差也是一个IEnumerable<Animal>，那么没有使用了“快捷方式”。 Count 扩展方法仅检查运行时类型是否为ICollection<Animal>，它不是（无协方差）。它无法检查ICollection<Cat>（它怎么知道Cat 是什么，它的TSource 参数等于Animal？）。

我举个例子：

static void ProcessAnimals(IEnuemrable<Animal> animals)
{
    int count = animals.Count();  // Linq extension Enumerable.Count<Animal>(animals)
    // ...
}

然后：

List<Animal> li1 = GetSome_HUGE_ListOfAnimals();
ProcessAnimals(li1);  // fine, will use shortcut to ICollection<Animal>.Count property

List<Cat> li2 = GetSome_HUGE_ListOfCats();
ProcessAnimals(li2);  // works, but inoptimal, will iterate through entire List<> to find count

我建议的检查IReadOnlyCollection<out T> 也会“修复”这个问题，因为这是一个由List<T> 实现的协变接口。

结论：

1. 在source 的运行时类型实现IReadOnlyCollection<> 但不是ICollection<> 的情况下，检查IReadOnlyCollection<TSource> 也是有益的，因为基础集合类坚持作为只读集合类型并因此希望不实施ICollection<>。
2. （新）如果适用通用协方差，即使source 的类型同时为ICollection<> 和IReadOnlyCollection<>，检查IReadOnlyCollection<TSource> 也是有益的。具体来说，IEnumerable<TSource> 可能实际上是ICollection<SomeSpecializedSourceClass>，其中SomeSpecializedSourceClass 可以通过引用转换为TSource。 ICollection<> 不是协变的。但是，IReadOnlyCollection<TSource> 的检查将通过协方差进行；任何IReadOnlyCollection<SomeSpecializedSourceClass> 也是IReadOnlyCollection<TSource>，将使用快捷方式。
3. 成本是每次调用 Linq 的 Count 方法时额外进行一次运行时类型检查。

Answer 1

在许多情况下，实现IReadOnlyCollection<T> 的类也将实现ICollection<T>。因此，您仍将受益于 Count 属性快捷方式。

例如，请参阅ReadOnlyCollection。

public class ReadOnlyCollection<T> : IList<T>, 
    ICollection<T>, IList, ICollection, IReadOnlyList<T>, IReadOnlyCollection<T>, 
    IEnumerable<T>, IEnumerable

由于检查其他接口以获得超出给定只读接口的访问权限是一种不好的做法，因此这种方式应该没问题。

对Count() 中的IReadOnlyInterface<T> 实施额外的类型检查将为对未实现IReadOnlyInterface<T> 的对象的每次调用提供额外的镇流器。

Answer 2

基于MSDN documentation，ICollection<T> 是唯一获得这种特殊处理的类型：

如果源的类型实现了 ICollection，则该实现用于获取元素的计数。否则，此方法确定计数。

我猜他们不认为为了优化而弄乱 LINQ 代码库（及其规范）是值得的。有很多 CLR 类型都有自己的 Count 属性，但 LINQ 无法涵盖所有​​这些。