[Proposal]: [Infer Func/Action argument types]

[Alex2357]

Type inference for Func/Action arguments and returned value

• Proposed
• Prototype: Not Started
• Implementation: Not Started
• Specification: Not Started

Add type inference for arguments in Func/Action declarations

I've coded using C# many years then for a while in F#, then in a new position in C#. Very frustrated with the fact that I have to write code similar to that one

            Func<string, MatchKind, string, PolicyConfiguration<RequiredReviewerPolicySettings>> createPolicy = (filenamePatterns, matchKind, refName) => 
                Model.Create<PolicyConfiguration<RequiredReviewerPolicySettings>>()
                 .Set(
                     x =>
                     {
                         x.IsEnabled = true;
                         ...
                     });

Why I need to write this whole noisy thing Func<string, MatchKind, string, PolicyConfiguration<RequiredReviewerPolicySettings>> ?
I understand compiler wants to know if I'm declaring lambda or Func. Then I'd like to write something like

            Func<...> createPolicy = (filenamePatterns, matchKind, refName) => 
                Model.Create<PolicyConfiguration<RequiredReviewerPolicySettings>>()
                 .Set(
                     x =>
                     {
                         x.IsEnabled = true;
                         ...
                         ...
                     });

giving a hint to compiler that this is Func and the rest I'd like compiler to figure out the way F# does.

or something like below, not fast on syntax, the important moment is I do not wanna repeat argument types of a Func or Action I would like compiler to figure out them from usage same way as F# does.

            var createPolicy = Func... (filenamePatterns, matchKind, refName) => 
                Model.Create<PolicyConfiguration<RequiredReviewerPolicySettings>>()
                 .Set(
                     x =>
                     {
                         x.IsEnabled = true;
                         ...
                         ...
                     });

Code clarity and less unnecessary noise

I wanna write less code and have less noise in my code. The more noise the more distractions and more bugs.

[svick]

I think there are several issues with this suggestion:

1. In C#, declarations can always be understood on their own, without looking at the initializer or body of the declared member. The C# compiler takes advantage of this and changing it would probably require changing the architecture of the compiler, so the benefit would have to be really high.
2. How exactly would the compiler infer the types of the parameters? I think many of the things F# does here (like compiling a local variable into a generic function) would not be appropriate for C#.

[Alex2357]

In C#, declarations can always be understood on their own, without looking at the initializer or body of the declared member.

I'm afraid I may not correctly understand what you mean. Could you explain this?

How exactly would the compiler infer the types of the parameters?

Compiler already does type inference when you're using var keyword. Ideally I'd like to be able to use var keyword, but the problem is that compiler doesn't have a clue if I have defined Expression<Func<...>> or Func<...> that's the main reason I believe the var can not be used and compiler wants you to declare the type.

when compiler see's expression

(filenamePatterns, matchKind, refName) => 
                Model.Create<PolicyConfiguration<RequiredReviewerPolicySettings>>()
                 .Set(
                     x =>
                     {
                         x.IsEnabled = true;
                         ...
                         ...
                     });

It may infer easily types of parameters filenamePatterns, matchKind, refName from their usage and return type based on the return type of the expression (in my case method returns PolicyConfiguration type).
So compiler clearly can know it is either Func<string, MatchKind, string, PolicyConfiguration<RequiredReviewerPolicySettings>> or Expression<Func<string, MatchKind, string, PolicyConfiguration<RequiredReviewerPolicySettings>>>.
So I would like just to tell that this is Func without telling the types.

[HaloFour]

It may infer easily types of parameters filenamePatterns, matchKind, refName from their usage

The only way the compiler knows those types now is based on the actual delegate signature. Attempting to infer based on usage would be massively expensive and nearly always ambiguous.

[Alex2357]

It may infer easily types of parameters filenamePatterns, matchKind, refName from their usage

The only way the compiler knows those types now is based on the actual delegate signature. Attempting to infer based on usage would be massively expensive and nearly always ambiguous.

F# does it why C# can't do that?

[HaloFour]

F# doesn't have the same performance goals as C#, it can spend more time on inference.

There is a proposal to allow lambdas as initializers to inferred variables here: #4451

However, it seems that said syntax would only be allowed if the types of the parameters are explicitly specified.

[svick]

I don't know F# that well, but as far as I can tell, F# uses several strategies to make this work and I don't think they would be appropriate for C#.

For example:

1. Ignoring method overloading.

   F# doesn't use method overloading in its standard library and assumes that if only a single overload exists, it will always be the only one. For example the F# code fun x -> "foo".EndsWith(x) compiles fine on .Net Standard 2.0, but fails to compile on .Net Standard 2.1, because an overload was added. I don't think it would be acceptable if adding such an overload broke some C# code.

2. Inferring the type of a variable based on its usage.

   Consider the following F# code:

   let add = fun a b -> a + b
   printfn "%A" (add "a" "b")
   printfn "%A" (add 1 2)

   This doesn't compile, but it starts to work if you comment out either of the printfn lines, inferring add to be int -> int -> int or string -> string -> string. I don't think this kind of type inference belongs to C#.

3. Automatic generalization

   Sometimes, an F# variable is not really a variable. For example, if you do let f = fun x -> x, then f is more like a generic function than a variable. This leads to some confusing behaviors, like Object.ReferenceEquals(f, f) returning false. Once again, I don't think this would be appropriate for C#.