title: Is T[] not better than IEnumerable<T> as parameter type? (Considering threading challenges)
body: <p>Some programmers argue that it is better to pass <code>IEnumerable&lt;T&gt;</code> parameters over passing implementations like <code>List&lt;T&gt;</code>, and one of the popular reasons to do this is that the API is immediately usable in more scenarios because more collections will be compatible with <code>IEnumerable&lt;T&gt;</code> than any other specific implementation, e.g. <code>List&lt;T&gt;</code>.</p>
  
  <p>The more I dive into multi-threaded development scenarios, the more I am starting to think that <code>IEnumerable&lt;T&gt;</code> is not the correct type either and I will try to explain why below.</p>
  
  <p>Have you ever received the following exception while enumerating a collection?</p>
  
  <p><strong>Collection was modified; enumeration operation may not execute.</strong> (an InvalidOperationException)</p>
  
  <p><img src="https://i.stack.imgur.com/My0Y0.png" alt="Collection was modified exception"></p>
  
  <p>Basically what causes this is, you are given the collection on one thread, while someone else modifies the collection on another thread.</p>
  
  <p>To circumvent the problem, I then developed a habit to take a snapshot of the collection before I enumerate it, by converting the collection to an array inside the method, like this:</p>
  
  <pre><code>static void LookAtCollection(IEnumerable&lt;int&gt; collection)
  {   
      foreach (int Value in collection.ToArray() /* take a snapshot by converting to an array */)
      {
          Thread.Sleep(ITEM_DELAY_MS);
      }
  }
  </code></pre>
  
  <p>My question is this. <strong>Wouldn't it be better to code towards arrays instead of enumerables as a general rule</strong>, even if it means that callers are now forced to convert their collections to arrays when using your API? </p>
  
  <p>Is this not cleaner and more bullet-proof? (the parameter type is an array instead)</p>
  
  <pre><code>static void LookAtCollection(int[] collection)
  {   
      foreach (int Value in collection)
      {
          Thread.Sleep(ITEM_DELAY_MS);
      }
  }
  </code></pre>
  
  <p>The array meets all the requirements of being enumerable and of a fixed length, and the caller is aware of the fact that you will be operating on a snapshot of the collection at that point in time, which can save more bugs.</p>
  
  <p>The only better alternative I can find right now is the IReadOnlyCollection which will then be even more bullet proof because the collection is then also readonly in terms of item-content.</p>
  
  <p><strong>EDIT:</strong></p>
  
  <p>@DanielPryden provided a link to a very nice article <a href="http://blogs.msdn.com/b/ericlippert/archive/2008/09/22/arrays-considered-somewhat-harmful.aspx" rel="nofollow noreferrer">"Arrays considered somewhat harmful"</a>. And the comments made by the writer <em>"I rarely need a collection which has the rather contradictory properties of being completely mutable, and at the same time, fixed in size"</em> and <em>"In almost every case, there is a better tool to use than an array."</em> kind of convinced me that arrays are not as close to the silver bullet as I had hoped for, and I agree with the risks and loopholes. I think now the <code>IReadOnlyCollection&lt;T&gt;</code> interface is a better alternative than both the array and the <code>IEnumerable&lt;T&gt;</code>, but it kind of leaves me with the question now: Does the callee enforce it by having a <code>IReadOnlyCollection&lt;T&gt;</code> parameter type in the method declaration? Or should the caller still be allowed to decide what implementation of <code>IEnumerable&lt;T&gt;</code> he passes into the method that looks at the collection? </p>
  
  <p>Thanks for all the answers.  I learned a lot from these responses.</p>