Proposal: Infer generic type based on target

[HaloFour]

Copied from dotnet/roslyn#5429

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

[alrz]

I think this also should work:

IQuerable<int> M() => Array.Empty().AsQueryable();

public static T[] Empty<T>();
public static IQueryable<T> AsQueryable<T>(this IEnumerable<T>);

[Foxtrek64]

What are your thoughts on providing a (sane) default via an overload?

I could see it being useful in some cases, such as where an API developer would like to provide a default return type that can act as a catch-all (object or some kind of common interface or type) but still provide the ability to cast to the specified type as needed.

However, I could also see it causing some undesirable or perhaps unexpected behavior depending on implementation, especially if the user assumes no type parameter was needed because it was implied rather than because it fell back to a type-parameterless overload.

private readonly Dictionary<string, object> _dict;

public string Find(string key)
    => Find<string>(key);

public TResult Find<TResult>(string key)
{
    // Some sort of dummy lookup code
    return _dict[key] as TResult;
}

int id = item.Find("Id"); // Legal, as discussed by op.
var name = item.Find("name"); // Falls back to type-parameterless overload. Type becomes 'string'.

[AartBluestoke]

@Foxtrek64 that would mean that replacing a type with var is a breaking change. I suspect that makes this feature a non-starter.

[HaloFour]

@AartBluestoke

It's not a "breaking change" if you have to modify source to exhibit the different behavior. But I agree that this could be confusing behavior.

[jannickj]

I've been using a Result<TOk, TError> type lately and it seems very nice, but not being able to infer based on usage really is a huge downgrade to QoL:

Example:
This is what you have to write

public static Result<Word, ParseError> ParseWord(string word) 
{
    if (string.IsNullOrWhiteSpace(word))
    {
          return new Err<Word, ParserError>(ParserError.ContainsOnlyWhiteSpace); <--- easily inferable type params
    }
    ...
}

instead of

public static Result<Word, ParseError> ParseWord(string word) 
{
    if (string.IsNullOrWhiteSpace(word))
    {
          return new Err(ParserError.ContainsOnlyWhiteSpace);
    }
    ...
}

[YairHalberstadt]

I would love it if this were possible, but what is missing now is a spec for how such inference would work. In this case is especially tricky as Err is a subtype of Result. If anyone can come up with a suitable spec which would cover this case, I would strongly encourage them to open a proposal.

[xZise]

Maybe I'm overlooking something, but isn't there some kind of hierarchy between those types? Err<A, B> inherits Result<A, B>, so Err.A is the type of Result.A which is Word.

I'm thinking along those lines:

class Foo<A> : Bar<string, A> {}
class Bar<X, Y> : Baz<X, Y, X> {}
class Baz<TOne, TTwo, TThree> {}

public Baz<string, int, string> funky() {
    return new Foo();
}

Now Foo<A> is Bar<string, A> which then means it is Baz<string, A, string>. Now A is specified as int, and thus is Foo<int>. This would only fail if the type is lost somewhere in the hierarchy (lets say class Bar<X, Y> : Baz<string, int, string> {}).

[RikkiGibson]

This was raised as a possible solution for #3950.

[Richiban]

I'm chiming in here because I've personally encountered a number of situations where this would be really nice to have (almost all have been a similar situation to the OP, where you must repeatedly access untyped data).

Reduced to a minimal example, I just feel like this should work in C#:

DateTime dateTime = Parse("2023-01-01");

T Parse<T>(string s) where T : IParsable<T> => T.Parse(s, null);

I think it's philosophically consistent with all the other work that's been done lately on target-typing.

[huoyaoyuan]

With collection expressions, there's a new interesting case:

Func(Array.Empty<SomeLongTypeName>().ToAsyncEnumerable());
Func([].ToAsyncEnumerable()); // Not working now

[CyrusNajmabadi]

@huoyaoyuan extension methods on collection expressions will be in c#13