Proposal: Extend var to represent the 'currently implied type' in general.

[rawlinson]

Problem

Despite the introduction of var, redundancy is still common in field/property and optional argument declarations. There is also scope to simplify member access when the type is implied. Currently we have to write:

class C
{
     Dictionary<string, Func<int>> someMap = new Dictionary<string, Func<int>>();

     void M(PartialResultProcessing processing = PartialResultProcessing.NoPartialResultSupport, String s = String.Empty)
     {
        if (processing == PartialResultProcessing.ReturnPartialResults || processing == PartialResultProcessing.ReturnPartialResultsAndNotifyCallback)
        {
            type.GetProperties(BindingFlags.Public | BindingFlags.Static);
            ...
        }
     }
}

* Forgive the long lines - that's part of the point!

Existing Propsoals

Extending var to be allowed on the left-hand side of these assignments, #601/#1056, is difficult to implement and would, perhaps more importantly, lead to the API being implicit.

A well-received proposal to aid in field/property declarations is to allow a "Target-typed new expression" #100, which would allow Dictionary<string, Func<int>> someMap = new ().
In my eyes this would produce syntax that would look too close to tuples:

var p1 = (x, y);
Point p2 = new (x, y);
// and, if public static implicit operator Point((int, int) p) exists:
Point p2 = (x, y);

There are several proposals to shorten enum access, #764 which would allow MyEnumType myEnumTypeValue = .SomeValue; etc., and #321/#354 which also eliminate the dot:

void M(PartialResultProcessing processing = NoPartialResultSupport, String s = String.Empty)
{
   if (processing == ReturnPartialResults || processing == ReturnPartialResultsAndNotifyCallback)
   {
       type.GetProperties(Public | Static);
       ...
   }
}

However, that syntax leads to the same ambiguities that can be introduced by using static ... but in this case would not be opt-in, allowing code such as:

BindingFlags Public = BindingFlags.Public | BindingFlags.Static;
type.GetProperties(Public | FlattenHierarchy);

Also, non-local behaviour could easily be altered without a warning if, for example, a property with the same name and type is introduced.
It could also only be used where there is no ambiguity, so does not represent a general, consistent method for shortening enum access.

Note that neither of these proposals remove the redundancy from String s = String.Empty. I do not consider using static ... to be a solution, for anything!

Proposal

My proposal to address these issues is to extend var to be used beyond just declarations but also as a general currently-implied-type:

class C
{
     Dictionary<string, Func<int>> someMap = new var();

     void M(PartialResultProcessing processing = var.NoPartialResultSupport, String s = var.Empty)
     {
        if (processing == var.ReturnPartialResults || processing == var.ReturnPartialResultsAndNotifyCallback)
        {
            type.GetProperties(var.Public | var.Static);
            ...
        }
     }
}

var removes the redundancy whilst maintaining clear intent and only requires an increase in scope of an existing keyword.

This change would be semantically consistent with var's existing use, in that it would still refer to the currently implied type.
It also has precedence in the new parameterless default, which would be equivalent to default(var), potentially allowing the implementation to use the same code to deduce the type.

[HaloFour]

@rawlinson

In my eyes this would produce syntax that would look too close to tuples:

I believe that similarity is intentional: dotnet/roslyn#35 (comment)

This is attractive as a counterpart to deconstruction, and we are considering it for a future version of C#.