Please add Empty to ReadOnlyCollection<T>

[thargol1]

Background and Motivation

As it is a best practice for API's to return ReadOnlyCollection<T> instead of List<T> etc, it would be nice to have an easy way to create an empty ReadOnlyCollection<T>. On par with Array.Empty<T>().

As it is also a best practice to return an empty collection instead of null.

Proposed API

public class ReadOnlyCollection<T>
{
    public static ReadOnlyCollection<T> Empty { get; }
}

Usage Examples

public ReadOnlyCollection<Stuff> FindStuff(string filter)
{
    if (string.IsNullOrEmpty(filter)) return ReadOnlyCollection<Stuff>.Empty;
}

Tagging subscribers to this area: @eiriktsarpalis
See info in area-owners.md if you want to be subscribed.

[NN---]

Why not same way as in Array?

public class ReadOnlyCollection
{
    public static ReadOnlyCollection<T> Empty<T>();
}

[reflectronic]

That would require introducing a new type, which is probably not as desirable. There is prior art for doing it as proposed, e.g.
ImmutableArray<T>.Empty, ArraySegment<T>.Empty, Span<T>.Empty, etc.

[Clockwork-Muse]

... I assume you mean System.Collections.Generic.IReadOnlyCollection<T> (an interface), since System.Collections.Generic.ReadOnlyCollection<T> doesn't exist.

Generally, though, I'd probably be returning IEnumerable<T> (which is effectively read only), as opposed to IReadOnlyCollection<T>. If my caller wants to store it (instead of just processing it), that becomes their problem. At which point Enumerable.Empty<T>() exists.

IReadOnlyCollection<T> is more likely to be used as an input parameter, as opposed to a return parameter/property (although, again, likely sees less use than IEnumerable<T>. The only real difference is a Count property, which doesn't matter in many scenarios.).

[svick]

@Clockwork-Muse No, this issue is about System.Collections.ObjectModel.ReadOnlyCollection<T>. I also think that the interfaces you mention are a better choice, but Framework Design Guidelines mostly talk about ReadOnlyCollection<T>.

[Clockwork-Muse]

I mean, I knew that it existed, it just irks me that it's off in the ObjectModel namespace.
Although for some reason I thought it was part of a reflection namespace or something, which was driving part of my comments, probably.

[iSazonov]

PowerShell uses a custom ReadOnlyCollection.Empty implementation.
https://github.com/PowerShell/PowerShell/blob/3594ac60c790cc5d3b39ea0d956cc8ee8985d0c8/src/System.Management.Automation/engine/Utils.cs#L1546
(31 call sites)

[thargol1]

Generally, though, I'd probably be returning IEnumerable<T> (which is effectively read only), as opposed to IReadOnlyCollection<T>. If my caller wants to store it (instead of just processing it), that becomes their problem. At which point Enumerable.Empty<T>() exists.

A bit off topic:
Iterating IEnumerable<T> is still significantly slower (even in .Net 5 preview 6) than iterating an Collection or List with for(var i=0;....) (and the debugging experience is horrible, jumping all over the place.) Though Framework Design Guidelines are from 2008, they are still relevant, so I still prefer to use collections or lists as return values.
More and more of my code is migrating to Azure. Less CPU and less memory means lower billing.

Returning to the topic:
I now roll my own version of 'Empty' each time, but since many other objects have an Empty property, I thought it was a reasonable addition to .Net and maybe even with a little less memory allocation (not that new ReadOnlyCollection<T>(Array.Empty<T>) uses many allocations, but .Net internal code has more tricks available).

[SteveDunn]

The FDG are very out of date. IMO, it's preferalbe to return narrower types, such as interfaces.