For the last 6 months the BCL team has been hard at work shipping an out of band release of immutable collections for .Net. Most recently delivering an efficient implementation of ImmutableArray<T> http://blogs.msdn.com/b/dotnet/archive/2013/06/24/please-welcome-immutablearray.aspx
Unfortunately with every announcement around these collections I keep seeing the following going past in my twitter feed.
That looks neat. Next time I’m writing parallel code I’m going to try that out.
No, no no!!! Immutable types are not just for parallel code. They are very useful in even single threaded applications. Developers are missing out by thinking of them as a parallel only construct. Any time you want to enforce that the contents of a collection never change you should consider an immutable type.
This is just a small sample of cases where immutable collections are useful in day to day code. The more you use them the more uses you will find for them. At some point you may even find yourself asking the following question when writing up a type
Do I actually need to mutate this collection after I finish building it?
Generally speaking the answer to this is no. And this is why you should be using immutable types.
HEY! How did he know I was "that guy?" The guy who said, "That looks neat. Next time I’m writing parallel code ..." Now, after reading his post, I don't have that excuse and will just have to take another look at these. Oh well, it IS shinny and new... :)
Related Past Post XRef:
Threading threading safely with the Immutable Collections Preview from the BCL Team