Proposal: Infer generic type arguments from constructor arguments

[dsaf]

From code sample:

public class Sample
{
    public static void Main()
    {
        //Type arguments are provided explicitly - works.
        var expl = new Pair<int, string>(10, "Sample");

        //Type arguments should be inferred from ctor arguments - fails.
        var impl = new Pair(10, "Sample");

        //Both of these will work however:
        var imp = Tuple.Create(10, "Sample");
        var exp = Tuple.Create<int, string>(10, "Sample");
    }
}

public class Pair<T1, T2>
{
    public Pair(T1 first, T2 second)
    {
    }
}

[dsaf]

And it would be nice to extend this to #953 as well:

...
    [DefaultValue(150)]
    public int Id { get; set; }
...
public class DefaultValueAttribute<T> : Attribute
{
    public DefaultValueAttribute(T @value) {}
}

[HaloFour]

The one potential issue with this might be ambiguity. Pair and Pair<T1, T2> are two completely different types. If Pair was also in scope and also had a ctor that accepted two parameters then the compiler would be forced to choose the non-generic version for compatibility reasons (apparently even emitting new warnings is considered a breaking change).

How do you feel about open generic type syntax, if only for cases where there could be ambiguity?

var pair = new Pair<,>("string", 1);

[dsaf]

@HaloFour

if only for cases where there could be ambiguity

Maybe.

[stas-sultanov]

It's also posible that there will be no more need in types like Pair, cause if we will take a look at Tuple class we will notice that it is created just because c# does not support requested feature.

[aluanhaddad]

I believe this was a post stating that this feature was being seriously considered at some point. It may have been on the old codeplex site or it may have been in an early C# 6 possible feature list document, but I do not remember.
Anyway, I think this would be a nice convenience.

@HaloFour Given the potential ambiguity, I would actually prefer that the full generic syntax

new Pair<string, int>("string", 1)

be required to disambiguate as opposed to the open generic syntax of

new Pair<,>("string", 1)

because I feel the former is clearer.

[mpawelski]

I remember that when when C#6 preview was first introduced in @MadsTorgersen talk he said they will implement this feature:
https://vimeo.com/84677184 (around 52 minute)
I remember that I asked about this feature on codeplex because I didn't noticed in any Design Note why they discarded it and stopped talking about it. I also asked if type parameter would be inferred from property and collection initializer initializer too (same as ##1470).

I think that this feature (#2319) and #1470 would be very nice improvement to C# type inference.

I hope C# language team would discuss it on their language design meetings.

I also would like to have all the other type inference improvements.
Now I hate "switching" back to providing a type name when all my methods' bodies use "var".

[gafter]

We are now taking language feature discussion on https://github.com/dotnet/csharplang for C# specific issues, https://github.com/dotnet/vblang for VB-specific features, and https://github.com/dotnet/csharplang for features that affect both languages.

We once considered doing this, but I think we are more likely to be interested in target-typed new expressions dotnet/csharplang#100