Question: I often need to return empty collections.  

One of those days I wrote the following to return a cached instance:

```
public static class Array<T>
{
    // As a static field, it gets created only once for every type.
    public static readonly T[] Empty = new T[0];
}

```

I didn't know about `Enumerable<T>.Empty()` maybe it didn't exist back then. Although I know now, I still use this one.

There are still many functions in BCL that need an array instead of `IEnumerable<T>`, `IList<T>` or `IReadOnlyList<T>`. And array implements all of these so it can be used anywhere.

```
// All these variables share the same array's reference.
string[]            empty1 = Array<string>.Empty;
IEnumerable         empty2 = Array<string>.Empty;
IEnumerable<string> empty3 = Array<string>.Empty;

```

What do you think about this class?  

Can you see any other advantages/disadvantages of it over `Enumerable<T>.Empty()`? 

And about implementation:  

Do you think making the caching using a static field would cause any problem?

---

Edit: Array class now has a static, generic [Empty](https://docs.microsoft.com/dotnet/api/system.array.empty) method, essentially deprecating this implementation.

Answer: 
Your solution is absolutely correct and practical. 

In fact `Enumerable.Empty<T>` also returns empty array under the hood, just slightly in a different way (they have a separate instance holder class that is lazily initialized).
I think it entirely depends on context.

`Enumerable<T>.Empty()` was clearly introduced for syntactic sugar in Linq. I see no reason to use it over a plain old new-statement.

The wider question about caching and efficiency depends on the code-base. Calling a list "Empty" explicitly states intent and could help readability, but if you later go on to add items to that collection in any way, it actually makes the code more confusing.

As far as any problems with the "cached, static" field go, the obvious problem is that if someone was foolish enough to place a lock on that static list, it could cause all manner of issues in your application as it'd act as a point of coupling.

I'd *always* avoid using shared static references if you don't need them for any specific reason, especially if it's a perceived performance problem that has never been encountered. You can't really get much safer than an instance variable with a new empty list in it.

Conversely, if you're really up against the wire with performance, there may be a good reason here, but you'd probably find that if you're micro-optimising list initialisation, there's a better higher level optimisation to be made.