Метод Linq Enumerable.Count проверяет ICollection‹›, но не IReadOnlyCollection‹›

Фон:

Linq-To-Objects имеет расширение метод Count() (перегрузка не взятие сказуемого). Конечно, иногда, когда метод требует только IEnumerable<out T> (для выполнения Linq), мы действительно передаем ему «более богатый» объект, такой как ICollection<T>. В этой ситуации было бы расточительно выполнять итерацию по всей коллекции (т. е. получить перечислитель и «перейти к следующему» целую кучу раз), чтобы определить количество, поскольку существует тег свойство ICollection<T>.Count для этой цели. И этот «ярлык» использовался в BCL с самого начала Linq.

Теперь, начиная с .NET 4.5 (2012 года), есть еще один очень приятный интерфейс, а именно IReadOnlyCollection<out T>. Это похоже на ICollection<T>, за исключением того, что включает только те элементы, которые возвращают T. По этой причине он может быть ковариантным в T ("out T"), точно так же, как IEnumerable<out T>, и это действительно хорошо, когда типы элементов могут быть более или менее производными. Но у нового интерфейса есть собственное свойство IReadOnlyCollection<out T>.Count. См. в другом месте на SO, почему эти свойства Count различны (вместо одного свойства).

Вопрос:

Метод 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 called
MyOtherColl.Count called

из запуска кода, который показывает, что «ярлык» не использовался в первом случае (IReadOnlyCollection<out T>). Тот же результат виден в 4.5 и 4.5.1.

ОБНОВЛЕНИЕ после комментария пользователя supercat о переполнении стека в другом месте.

Конечно, 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) это привело к тому, что если метод расширения Linq Count использовался для источника типа времени компиляции IEnumerable<Animal>, где фактический тип времени выполнения был, например, 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. Также проверка IReadOnlyCollection<TSource> будет полезной в тех случаях, когда тип времени выполнения source реализует IReadOnlyCollection<>, но не ICollection<>, потому что базовый класс коллекции настаивает на том, чтобы быть типом коллекции только для чтения и, следовательно, желает не реализовать ICollection<> .
2. (новое) Также полезна проверка на IReadOnlyCollection<TSource>, даже если тип source является одновременно ICollection<> и IReadOnlyCollection<>, если применяется общая ковариация. В частности, IEnumerable<TSource> на самом деле может быть ICollection<SomeSpecializedSourceClass>, где SomeSpecializedSourceClass преобразуется путем преобразования ссылки в TSource. ICollection<> не является ковариантным. Однако проверка на IReadOnlyCollection<TSource> будет работать по ковариации; любой IReadOnlyCollection<SomeSpecializedSourceClass> также является IReadOnlyCollection<TSource>, и будет использоваться ярлык.
3. Стоимость составляет одну дополнительную проверку типа во время выполнения за вызов метода Linq Count.