Future Directions

When thinking about the future of a language, there's always a tension between the desire to add new features and the desire to keep the language simple. ^[10] There are a lot of possible features that could be added to C#, but only some of them will make the cut. At the time of this writing, we're focused on shipping the initial version of C# and haven't spent much time discussing which features will be added in the future.

^[10] This idea is sometimes expressed as " Simplicity is a feature."

One feature that we'd like to have, however, is generics ( otherwise known as parameterized types). C# does have a limited type of genericity, in that every type can be stored as an object. This allows the creation of collection classes that can store any type. This approach works, but there are a few unfortunate consequences. Consider the following code:

 ArrayList arr = new ArrayList();  arr.Add(1); arr.Add(2); int value = (int) arr[0]; 

Because the integers 1 and 2 are value types, they have to be boxed to be stored in the ArrayList , which stores only values of the type object . When the values are boxed, this requires an extra heap allocation for the box, which has some performance implications.

A second issue is the cast to int when accessing the value. Having to use this feature adds a bit of ugliness to your code, but more importantly, there has to be a runtime check to see whether the item from the ArrayList is really an integer. In other words, this code is runtime type-safe, but not compile-time type-safe.

If you had generics, you could write something like the following:

 ArrayList<int> arr = new ArrayList<int>();  arr.Add(1); arr.Add(2); int value = arr[0]; 

In this case, there are no boxing and no casts.