Discussion: Explicitly typed "var" declarations in C#

[jonathanmarston]

Problem

You can currently define variables in 3 ways using explicit types or an implicit type using the var keyword:

// Explicitly typed
Dictionary<string, string> variable;

// Explicitly typed with initializer
Dictionary<string, string> variable = "hello";

// Implicitly typed with initializer
var variable = new Dictionary<string, string>();

This is fine when either all variable declarations are explicit, or when all of them are implicit. However, because there is no way to specify a type using the var keyword, the type and the variable are flip-flopped when writing code where some variables are initialized, and others aren't initialized, or are initialized to null.

Example:

var singleString = "hello";
Dictionary<string, string> dictionaryOfStrings;
var listofStrings = new List<string> { "hi", "howdy" };
Func<string, IEnumerable<char>> getCharacters = null;

This creates an inconsistent flow in the code, requiring the reader to switch sides of the declaration when looking for the type.

There is, in fact, a workaround of sorts, where you cast null to the desired type:

// Implicitly typed with null initializer
var variable = (Dictionary<string, string>)null;

However, this changes the meaning of the code by disabling the compiler check for reading a reference variable before assigning to it.

Proposed Solution

It would be helpful to increase consistency and readability of code if you could supply an explicit type when using the var keyword, without needing to initialize the variable.

With this proposal, the previous example would become:

var singleString = "hello";
var dictionaryOfStrings: Dictionary<string, string>;
var listofStrings = new List<string> { "hi", "howdy" };
var getCharacters: Func<string, IEnumerable<char>> = null;

The syntax here is borrowed from TypeScript, and makes variable declarations in C# read more closely to VB, where the var keyword can be consistently used, and the type consistently appears on the right-hand side of the declaration.

It would also be valid to specify a type and an initializer concurrently using the var keyword:

var enumerable: IEnumerable<string> = new List<string>();

Potential Issues

The main issue I see with this proposal is that some could view it as over-complicating the language by adding another way to say the same thing, but I'd argue that the var keyword has already done that. This proposal is simply allowing developers that have embraced var to use a more consistent syntax throughout their code.

[jnm2]

I prefer either of these:

var dictionaryOfStrings = (Dictionary<string, string>)null;
var dictionaryOfStrings = default(Dictionary<string, string>);

to var dictionaryOfStrings: Dictionary<string, string>;

Since we have out variables, I don't see a common need to declare a variable without initializing it to a value and I like the explicitness of writing null or default.

[jonathanmarston]

I'd agree with you if null or default were equivalent to what I proposed, but this:

var dictionaryOfStrings: Dictionary<string, string>;
dictionaryOfStrings["greeting"] = "Hello";

Would raise a "Use of unassigned local variable 'dictionaryOfStrings'" compiler error, while this:

var dictionaryOfStrings = (Dictionary<string, string>)null;
dictionaryOfStrings["greeting"] = "Hello";

Compiles just fine.

Also, null and default wouldn't work if nullable reference types become a reality.

[jnm2]

@jonathanmarston That was my (poorly made) point. I don't see a common need to declare a local without initializing it to a value. In the very rare cases where this happens, (T)null works for readability just fine even though it's unnecessary initialization. And half the time, you'll refactor and need to end up initializing to null anyhow.

[svick]

I don't think it makes sense to add alternative syntax for declaring variables just to make some code somewhat prettier. Especially considering that:

1. I think that uninitialized variables are not used that often. And the same applies applies to variables whose initializer does not have a type (null, lambda).
2. Uninterrupted sequences of only assignment statements probably don't tend to be that long.
3. Even the example code has the types only roughly in the same position, they are not actually aligned that well.
4. When reading code, you usually care about more than just the variable name and type, in which case this proposal would not help.

[MgSam]

So you want to add a language feature for the handful of cases when you're in this scenario, so that your code is more symmetric? That hardly seems worth the cost of adding another means of specifying types into the language.