IIListProvider<T> is non-public

[ActivistInvestor]

How does a user type that implements IEnumerable<T> provide a result to TryGetNonEnumeratedCount() ?

It doesn't seem possible. IIListProvider<T> is an internal interface. I can't implement it on my type that implements IEnumerable<T>, and I'm at a loss to explain why that is.

Any insights on that?

[huoyaoyuan]

How does a user type that implements IEnumerable<T> provide a result to TryGetNonEnumeratedCount() ?

You should just implement ICollection<T> or IReadOnlyCollection<T> and provide Count. Having one type changes the ability of getting count is not a good design.

IIListProvider<T> is just a LINQ implementation detail. It's used for better optimization of chained LINQ operators.

User code should just implement IList<T> or IReadOnlyList<T>. ICollection<T>.CopyTo can be used to provide some optimization.

[ActivistInvestor]

You should just implement ICollection or IReadOnlyCollection and provide Count. Having one type changes the ability of getting count is not a good design.

I can't implement ICollection<T> or IReadOnlyList<T>. The types in question implement only IEnumerable<T>, because they cannot always provide a Count, and that isn't known at design-time.

If TryGetNonEnumeratedCount() is not applicable to any IEnumerable<T>, then it shouldn't be public. It should be an implementation detail also, since it cannot query any user type that implements IEnumerable<T>.

[tannergooding]

If TryGetNonEnumeratedCount() is not applicable to any IEnumerable, then it shouldn't be public

The entire point is that its a "try" API, it attempts to get the count. It is a best attempt using the broadly available existing interfaces.

Some new interface could theoretically be provided, but checking if a T implements an interface has an actual expense at runtime and adds overhead to every caller. A net new interface that would be implemented by a minority of types that could sometimes, but not always, have a count isn't necessarily worth the additional complexity. It's the same reason why LINQ doesn't check for IReadOnlyCollection<T> (a .NET Framework 4.5 interface) in most cases, it only checks for ICollection<T> instead

[huoyaoyuan]

The types in question implement only IEnumerable<T>, because they cannot always provide a Count, and that isn't known at design-time.

This is the anti-pattern. Collections with different capabilities should be implemented in different types, potentially sharing a common base type.

[KennethHoff]

Ironically, this interface was removed mere days after you made this discussion 🤣

#98969