Proposal: Stronger type Inference for generics calls

[iam3yal]

So today, C# can infer the type from the context for types like this:

var x = 1; // int
var y = "one"; // string
var z = 1f; // float

Now, when it comes to generics, say we have the following class:

class Foo<T>
{
    public Foo(T value)
    {
    }
}

When we are creating Foo we must satisfy the generic argument and provide the type explicitly like this:

var x = new Foo<int>(1);
var y = new Foo<string>("one");
var z = new Foo<float>(1);

Now, in C# 7 there's a new feature to allow C# to infer the type from the argument or whatever context it might be when the type is known instead of specifying the the actual type explicitly like this (which is just beautiful imo):

Foo(new (1, "one"));

So what I'm proposing is the ability to have stronger type inference for generics calls this means you no longer need to satisfy the type argument because it would be inferred by the compiler so in the future we might have the ability to write the following code instead of the above:

var x = new Foo(1); // int
var y = new Foo("one"); // string
var z = new Foo(1f); // float

With my proposal the following will also be allowed so this is an addition to the C# 7.0 feature even though the C# 7.0 feature is more succinct:

Foo(new Bar(1, "one")); // Bar<T, U>

When it comes to overload resolution in cases like this:

class Foo<T>
{
    public Foo(T value)
    {
    }

    public Foo(object value)
    {
    }

    public Foo(int value)
    {
    }
}

I don't know what's the best approach to go with here but I'd assume it should pick the generic constructor over anything else.

The aim here is to make the code more readable and less explicit when it makes sense, in my opinion whether something is generic or not shouldn't concern the person that reads the code.

It's not like we handle things differently if something is generic, we just write it differently and I guess we can make it look like a normal code without all the verbosity and ceremony that generics brings, at least where we make the calls.

[HaloFour]

Dupe of #2319. You do have the following ambiguity issue:

public class Foo {
    public Foo(int value) { }
}

public class Foo<T> {
    public Foo(T value) { }
}

var foo = new Foo(123);  // Foo(int) or Foo<int>(int)  ?

For the sake of compatibility the result would have to be a Foo and not a Foo<int>, but that might not be what the developer expects.

[iam3yal]

@HaloFour Okay, what do you think about this then?

var foo = new Foo<>(123);

We can use this syntax instead when there's ambiguity? or just use it everywhere.

[iam3yal]

@HaloFour Okay, I see that @aluanhaddad already proposed something similar to disambiguate. :)

[aluanhaddad]

@HaloFour I actually think the developer would expect the non generic class to be instantiated because it is more specific.