Proposal: Partial type inference

[Quantumplation]

Hello!

I often run into situations where I would like to partially specify the types, but the rest can be inferred from the parameters. For example, when building a "Validation Rule" system, where validation rules are encapsulated as composable objects:

    return NotNull<MyObject, string>(x => x.StringField);

I can't think of any reasons (granted, I'm not as well placed to think of problems as some other people here might be) that it wouldn't be able to infer the second type, as follows:

    return NotNull<MyObject>(x => x.StringField);

As it stands now, I usually use an intermediate object or function which splits the type parameters up, but this gets awkward.

Similarly, it would be great if type inference was available on constructors!

    new Foo(stringField);

would translate to

    new Foo<String>(stringField)

[paulomorgado]

What happens if you have both NotNull<T1, T2> and NotNull<T>?

I would prefer something like NotNull<T1, ?>.

[dsaf]

Last suggestion is a duplicate of #2319.

[erik-kallen]

I think a solution that allow you to partially constrain type resolution would be a nice addition. Like:

Tuple<IDictionary<int, IList<string>>, int> MyMethod()
{
    Dictionary<int, List<string>> something = SomeMethod();
    return Tuple.Create((IDictionary<*, IList<*>)something, 0);
}

[taori]

Yes. I'm running into this issue a lot too. It's very inconvenient to duplicate compilation information which can be infered. That and #2319 would be very convenient.

[gafter]

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

See also #18002 for a general discussion of closing and/or moving language issues out of this repo.