New Ways to Initialize Collections in C# 6
Like this article? We recommend
Like this article? We recommend
Like this article? We recommend
This article discusses another C# enhancement in release 6 that brings C# in line with VB.NET, along with a new feature that brings consistency to collection initialization in both languages.
When collection initializers were added in C# 3, the syntax supported sequence containers (lists, arrays, and similar structures), but not associative containers (dictionaries, hash sets, and similar structures). The latest versions of the language have added that missing feature.
In addition, collection initializers relied on an accessible Add method, with C# requiring the Add method to be a member method. In the VB.NET implementation, the Add method could be an extension method. C# has corrected this limitation in the current version.
Initializer Syntax
Let's begin by exploring the syntax. As a refresher, the collection initializer syntax for sequence containers enables you to declare a sequence container variable, initializing it with a number of elements:
List<Person> authors = new List<Person> { new Person { FirstName = "Bill", LastName = "Wagner" }, new Person { FirstName = "Eric", LastName = "Lippert" }, new Person { FirstName = "Mark", LastName = "Michaelis" } };
In previous versions, if you wanted to perform something similar with an associative container, you were out of luck. Dictionary<TKey, KValue> didn't have an Add method that took a single parameter.
Collection initializers required an Add method that took only one parameter, distinguishing them from Add() methods that semantically created the sum of two items. The language designers felt that if a type had an Add(a,b) method, it likely performed "addition" on a and b, with whatever semantics that might mean for the type. The rule codified the heuristic that an Add() with a single parameter added an item to a collection, whereas Add() with two parameters performed addition.
This rule prevented associative containers from using collection initializers. The Add() method for most associative containers needed two parameters: the key and the value.
C# 6 brings a new initializer syntax to specify the key and the value for a new pair to add to an associative collection. The key goes between brackets ([ ]), and the value goes to the right of an equals sign (=). The syntax is similar to an assignment to a new value added to the collection:
Dictionary<string, Person> authorsAndBooks = new Dictionary<string, Person> { ["Effective C#"] = new Person { FirstName = "Bill", LastName = "Wagner" }, ["Essential C# 6.0"] = new Person { FirstName = "Eric", LastName = "Lippert" }, ["Essential C# 4.0"] = new Person { FirstName = "Mark", LastName = "Michaelis" } };
Internally, this syntax generates a call to the Dictionary's indexer method. It's the equivalent of the following initialization and indexer statements:
Dictionary<string, Person> authorsAndBooks = new Dictionary<string, Person>(); authorsAndBooks["Effective C#"] = new Person { FirstName = "Bill", LastName = "Wagner" }; authorsAndBooks["Essential C# 6.0 "] = new Person { FirstName = "Eric", LastName = "Lippert" }; authorsAndBooks["Essential C# 4.0 "] = new Person { FirstName = "Mark", LastName = "Michaelis" };
The new syntax just reads more naturally. It also gives associative containers and sequence containers more parity in terms of initialization.
There is one caution. The new initializer syntax calls the indexer method to add items to the collection. That same indexer method replaces items as well as adding items. Consider this change to my earlier example:
Dictionary<string, Person> authorsAndBooks = new Dictionary<string, Person> { ["Effective C#"] = new Person { FirstName = "Bill", LastName = "Wagner" }, ["Effective C#"] = new Person { FirstName = "Eric", LastName = "Lippert" }, ["Effective C#"] = new Person { FirstName = "Mark", LastName = "Michaelis" } };
After executing this code, the authorsAndBooks collection has only two items, not three. The third initialization statement hasn't added a third item; instead, it replaced the second item in the collection. Because the second and third lines have the same key, they're stored in the same slot in the associative container. There are no compile-time checks on this likely mistake. It's legal C#, and therefore allowed.
Extension Add Methods
Support for using an Extension method for Add generally isn't needed, but it comes up from time to time. Consider this class:
public class Conversation : IEnumerable<string> { private List<string> messages = new List<string>(); public void Append(string message) { messages.Add(message); } public IEnumerator<string> GetEnumerator() { return messages.GetEnumerator(); } IEnumerator IEnumerable.GetEnumerator() { return GetEnumerator(); } }
The developer created an Append method, instead of the typical Add method, to add a new message to a conversation. Because of that API decision, the following code doesn't compile:
Conversation argument = new Conversation { "Is this the right room for an argument?", "I've told you once.", "No you haven't", "Yes I have", "When?", "Just now!", "No you didn't.", "Yes I did!", "Didn't", "Did" };
It doesn't compile because there's no accessible Add method. (It's also far too silly.) The compiler sees the initializer code and needs to generate a call to Add(), but the Conversation class has no Add() method. In C# 6, you can easily fix this issue by creating your own extension method called Add that has the proper signature:
public static class Extensions { public static void Add(this Conversation c, string m) { c.Append(m); } }
The compiler-generated call to Add can now resolve to an extension method. This simple fix wouldn't work in previous versions of C#, though the VB.NET compiler has supported this construct since the language added collection initializers. In fact, the C# compiler didn't support this syntax only because of a check to specifically disallow extension methods. In version 6, that check has been removed.
Initial Guidance on Collection Initialization
Neither of these features has had a large impact on the code that I write on a daily basis, though I appreciate the new associative-container initialization syntax when my design uses those containers. It makes the language more consistent, and it reads better. Similarly, I don't often need the extension's Add method syntax; however, when an API for a collection type doesn't have an accessible Add method, and I can't change that collection type, the Add method syntax is very useful.
Because these changes are small and incremental, I haven't updated existing code to use the new features. When the existing code works, I leave it alone.