今天，我阅读了Eric Lippert的一篇描述the harm of arrays的帖子。提到了当我们需要值的集合时，我们应该提供值，而不是指向值列表的变量。因此，埃里克（Eric）建议，只要我们想在方法中返回项目的集合，就应该返回IList<T>，它提供与数组相同的功能，即它：
启用索引访问
可以迭代项目
强类型
但是，与数组相反，该列表还提供添加或删除项目并因此修改集合对象的成员。我们当然可以将集合包装为ReadOnlyCollection并返回IEnumerable<T>，但随后我们将失去索引的可访问性。而且，调用者无法知道ReSharper警告“相同枚举的可能迭代”是否适用，因为调用者不知道内部枚举只是包装在ReadOnlyCollection中的列表。因此，呼叫者无法知道该集合是否已经实现。
因此，我想要的是一个集合本身是不可变的项目集合（这些项目不是必须的，它们也不会在IList上），这意味着我们不能在其中添加/删除/插入项目基础列表。但是，从我的API返回ReadOnlyCollection似乎很奇怪，至少我从未见过API这样做过。
因此，数组似乎很适合我的需求，不是吗？
最佳答案
我们当然可以将集合包装为ReadOnlyCollection并返回IEnumerable<T>
为什么这样ReadOnlyCollection<T>实现IList<T>，因此，除非有更好的方法，否则声明一个IList<T>的返回类型并返回一个ReadOnlyCollection<T>的实例似乎是一个好方法。
但是，碰巧的是，在当前的.NET Framework版本中，有一种更好的方法：返回ReadOnlyCollection<T>的实例，但指定IReadOnlyList<T>的返回类型。尽管IList<T>并未真正承诺允许调用者进行修改，但IReadOnlyList<T>明确表明了其意图。
关于c# - IList是否真的是数组的更好替代品，我们在Stack Overflow上找到一个类似的问题：https://stackoverflow.com/questions/39746956/