Proposal: Infer generic type based on target

[HaloFour]

Problem

When calling generic methods where the generic type parameter is only used as the return value of the method there is currently no inference which leads to repetition.

DataTable table = ...;
var people = table.Rows
    .Select(row => new Person {
        Id = row.Field<int>("id"),
        Name = row.Field<string>("name"),
        Birthdate = row.Field<DateTime>("dob")
    })
    .ToList();

Proposal

It would be convenient if in the specific case of the generic type parameter being the return type if the compiler could infer the generic type argument based on the destination of the result. This would only be permitted if the method is called in an unambiguous fashion. The return value must be assigned to a destination with an explicit type and there can be no other non-generic methods with the same name and parameters.

int id = row.Field("id"); // legal, generic type argument inferred to be int
var id = row.Field("id"); // not legal, circular inference
row.Field("id"); // not legal, no assignment to a type

[orthoxerox]

Is it really that much easier/neater to write the first line instead of the second?

LocationComponent loс = entity.Get();
//vs
var loc = entity.Get<LocationComponent>();

I personally feel betrayed by the compiler every time I have to write the type of a local instead of using var (out parameters, conditional assignment etc). :)

[alrz]

Additional use case in properties and/or methods based on return type:

 // calls fields.Get<int>("Id") utilizing CallerMemberNameAttribute
public int Id => fields.Get();

[HaloFour]

@orthoxerox

In that scenario it's definitely not an improvement. I'm thinking specifically of scenarios where the target is already defined, whether it be an existing variable or a property. The inspiration for this is in the proposal itself, someone I work with complaining about having to explicitly specify the generic type argument when calling the DataRow.Field<T> extension method when the result was being directly assigned to a property in an object initializer.

[dsaf]

What if there is a non-generic overload of the Field method? Would you do what you have suggested in #2319 (which is somewhat related):

new Something
{
    Id = row.Field<>("id"),
    ObjValue = row.Field("obj")
}

[dsaf]

I think this proposal could make a good impact when using mocking frameworks such as NSubstitute and FakeItEasy:

A.CallTo(() => foo.Bar("hello", A<int>.Ignored)).MustHaveHappened();

calculator.Add(Arg.Any<int>(), 5).Returns(7);

vs

A.CallTo(() => foo.Bar("hello", A.Ignored)).MustHaveHappened();

calculator.Add(Arg.Any(), 5).Returns(7);

[alrz]

Also for default(T) this could be useful.

obj match(... case * : default);

[gafter]

I marked this as "Need More Info", as we'd like you to suggest what modifications to the type inference specification you'd like to see to address this.

[HaloFour]

@gafter

I'll try to do my best to hammer that out. I don't think I've seen any examples in the spec of type inference occurring in this direction so I don't know how well it can be accomplished through minor updates to the spec. Spec-writing is far from my strong-suit so please be patient with me. 😁

Under §7.5.2:

If the supplied number of arguments is different than the number of parameters and the return value in the method, then inference immediately fails. Otherwise, assume that the generic method has the following signature:

T_r M<X₁…X_n>(T₁ x₁ … T_m x_m)

With a method call of the form E_r = M(E₁ …E_m) the task of type inference is to find unique type arguments S₁…S_n for each of the type parameters X₁…X_n so that the call E_r = M<S₁…S_n>(E₁…E_m) becomes valid.

The use of the assignment operator is only to indicate that the assignment of the return value is to play a part in the type inference. That may not be the best syntax but the goal is to indicate that as long as the type of the target of the assignment is known that it can be used for type inference. The simplest scenario would be when the return value is being assigned to an explicitly typed variable, field or property. Expanding that to method arguments would be ideal but I can see situations where that would result in circular inference.

Under §7.5.2.1:

For the method return value E_r:

• If the value to which E_r is being assigned to has a type U then an upper-bound inference is made from U to T_r.

I'm not sure changes to the other section would apply as I don't intend to alter how existing type inference works, only apply the target type in the cases where current inference would fail. For example:

// given:
T M1<T>(T x1) { ... };
T M2<T>(params T[] x) { ... }
TR M3<T, TR>(T x) { ... }

// infers M1<string>, compiler error
int x1 = M1("foo");

// infers M2<int>
int x2 = M2();

// infers M2<string>, compiler error
int x3 = M2("foo");

// infers M3<string, int>
int x4 = M3("foo");