Question

Why can’t I use the array initializer with an implicitly typed variable?

string[] words = { "apple", "strawberry", "grape" };                 // legal
string[] words = new string[]{ "apple", "strawberry", "grape" };     // legal
var words = new []{ "apple", "strawberry", "grape" };                // legal
var words = new string[]{ "apple", "strawberry", "grape" };          // legal

var words = { "apple", "strawberry", "grape", "peach" };             // ILLEGAL

Is there a technical reason for this limitation? Why can’t it infer the type like it would for:

var number = 10;
var text = "Hello";

The compiler clearly knows what I am trying to do, it just won’t allow it:

CS0820: Cannot assign array initializer to an implicitly typed local

---

Update: I compiled a program using the four legal array declaration methods, and it generates the same IL: http://pastebin.com/28JDAFbL

This just adds to my confusion. And “it is like this because the spec says so” is of little help. Why is the spec like this? What is the rationale here?

Answer 1

Why can’t I use the array initializer with an implicitly typed variable? Why is the spec like this? What is the rationale here?

I was not on the design team when this decision was made, and the design notes(*) are silent on this subject. However, I asked someone who was in the room in 2005 when this decision was made.

The explanation is prosaic. The design team was never very happy with the array initializer syntax in the first place. Frankly it is downright bizarre that an array initializer is not an expression and syntactically can only appear in a local or field declaration. It complicates the parser. It seems strange that

int[] x = {1};

should be legal, but

M({1});

is not.

The array initialization syntax also makes error recovery during code analysis at edit time complicated. Suppose you have something like:

class C
{
    void M()
    {
        {
            int result = whatever();
            ...
        }
        {
            int result = somethingElse();
            ...
        }
    }
}

and you start typing a new declaration in the editor:

    void M()
    {
        int[] x = 
        {
            int result = whatever();

and suddenly now the parser has to deal with disambiguating the situation in a way that does not confuse the poor user who is about to type “null;”. Clearly you do not intend to initialize the local variable with the block of code, but the parser is perfectly within its rights to say that the brace can only legally be part of an array initializer here, and therefore it is the “int result” that is unexpected.

So, long story short, “classic” array initializers are a bit of a misfeature. We can’t get rid of them because of backwards compatibility reasons. But we also don’t want to encourage their use by allowing them in more places.

The design team came up with the idea of prepending “new[]” to the array initializer, and make that into a legal expression, and now the problem is solved. There is no “creep” of the classic array initializer misfeature into new areas of the language, and there is a terse but readable syntax that clearly says “you are making a new array here”.

The moral of the story is: try to get it right the first time, because syntax is forever.

---

(*) In my search I did discover several interesting things: the team originally believed that “var” probably would not be the keyword chosen for the feature; apparently it grew on them. Also, one design called for “var” locals to not just be implicitly typed, but also be init-once locals. Obviously we never did implement init-once locals.