Why use readonly IEnumerable<T>

Question

Why would you declare an IEnumerable<T> readonly?

From the this article on async & await we have the following code.

class OrderHandler
{
    private readonly IEnumerable<Order> _orders;

    public OrderHandler()
    {
        // Set orders.
    }
    public IEnumerable<Order> GetAllOrders()
    {
        return _orders;
    }
}

IEnumerable<T> is immutable. How is this different from the readonly keyword?

Answer 1

The readonly keyword here applies to the field _orders. It simply means that the field can not be assigned a different value during the lifetime of the object. For example, this is not possible:

class OrderHandler
{
    private readonly IEnumerable<Order> _orders;

    public OrderHandler()
    {
        // Set orders.
    }

    void SomeMethod()
    {
        _orders = new Order[0];
    }
}

You will receive this compiler error:

A readonly field cannot be assigned to (except in a constructor or a variable initializer)

This does not make the collection read-only. For example, you could still do this:

class OrderHandler
{
    public readonly IEnumerable<Order> Orders;

    public OrderHandler()
    {
        Orders = new List<Order>();
    }
}

((List<Order>)OrderHandler.Orders).Add(new Order());

Which would probably violate the thread-safety of the class. See Tigran's answer for information on immutable collections.

Further Reading

• readonly (C# Reference)

Answer 2

In addition would add that event if it defines _orders as immutable, this makes immutable only reference itself, but not the content of that collection. I still can change object inside that enumeration.

For this reason beginning from the C# 5.0, we will get :

Immutable Collections in .NET Framework

Quoting article:

Immutable Collections are collections which guarantees that they never change their content and completely thread safe

Answer 3

As others have noted, the readonly qualifier makes the reference stored in a class-object's class-type field immutable once the constructor of that object has finished, but has no such effect on any object to which the reference may refer. There is no plausible means by which the qualifier could affect in that way the object to which the reference refers, since other copies of the reference could exist stored in fields without such a qualifier.

That does not, however, imply that the readonly keyword cannot usefully be applied to mutable objects. Suppose one had a class Foo with a field stuff that held an IEnumerable<KeyValuePair<int,string>>, and one wanted it to expose a property Keys of a type which implements IEnumerable<int> containing the key-part of each item in stuff. If stuff is held a read-only field, then a wrapper object returned by Keys could hold a reference to stuff and have a "live view" of any changes to the collection. If, however, stuff were not a read-only field, then the wrapper object would have to have a reference to the Foo upon which the Keys property was called if it wanted to ensure that it would always behave as a live view.