Possible bug with inferred delegate types

[MVey]

See original post here:
https://stackoverflow.com/questions/77032027/do-c-sharp-10-inferred-delegate-types-involve-an-implicit-conversion

It seems that there is an issue with inferred delegate types, either in roslyn or in csharplang specification...

Generally, I think we can reasonably expect that, if this can compile:

var x = (my_expression); // inferred type
SomeType y = x;

...Then this single assignment should compile as well:

SomeType y = (my_expression);

However, this is not satisfied when inferred delegate types are involved.

Consider the code below:

using System;

class Program {

    class FunctionWrapper<Output> {
        private Func<Output> WrappedFunction { get; }
        public FunctionWrapper(Func<Output> function) => WrappedFunction = function;
        public static implicit operator FunctionWrapper<Output>(Func<Output> function) => new FunctionWrapper<Output>(function);
    }

    public delegate void DoStuffDelegate<Inout>(ref Inout Input);

    static void Main(string[] args) {

        var funcLambda = () => "hello"; // type is inferred here...
        FunctionWrapper<string> funcWrapper = funcLambda;  // ... it compiles
        // but if we do a single assignment...
        FunctionWrapper<string> funcWrapper2 = () => "hello"; // CS1660 - this does not compile anymore... Why?

        // the exact opposite happens with delegates:

        // if we do a single assignment...
        DoStuffDelegate<string> delegWrapper2 = (ref string input) => { input = input + input; }; // ... it compiles
        // but if type is inferred...
        var delegateLambda = (ref string input) => { input = input + input; }; // type is inferred
        DoStuffDelegate<string> delegWrapper1 = delegateLambda; // CS0029 - this does not compile anymore...        
    }
}

I have the impression that inferred delegate types imply an implicit conversion at some stage, which probably should not be the case.

(link to the code: https://godbolt.org/z/3sbd9ndrT)

I tried different compilers and searched for documentation, discussions, and potential known issues regarding the behavior of inferred delegate types, unsuccessfully.

Can somebody please tell if this is a language/compiler defect, or if my expectations for these conversions to work are unreasonable?

Thank you in advance.

[HaloFour]

This is expected.

Inferred delegate types will re-use any existing Action<...>/Func<....> delegate if the signature matches. Otherwise, C# will create its own delegate type. It's impossible to infer the natural delegate type for a lambda otherwise as delegates are nominally typed and do not have signature equivalence.

        // fine
        Predicate<int> pred1 = (int x) => x % 2 == 0;
        
        // not fine, pred is Func<int, bool>
        var pred = (int x) => x % 2 == 0;
        // error CS0029: Cannot implicitly convert type 'System.Func<int, bool>' to 'System.Predicate<int>'
        Predicate<int> pred2 = pred;

See: https://github.com/dotnet/csharplang/blob/main/proposals/csharp-10.0/lambda-improvements.md#delegate-types

[MVey]

Thanks, I understand the technical reason, it's really interesting.

However, I still think there is something fundamentally wrong here...
When doing:

var pred = (int x) => x % 2 == 0;

I really don't expect any kind of information loss regarding the initial type of the expression. this is quite confusing.
I would prefer not to have any inferrence at all rather than lossy inferrence to be honest.

As a conclusion, I guess it's worth noting that now, if this compiles in C#:

var x = (my_expression); // inferred type
SomeType y = x;

This might not compile in some cases:

SomeType y = (my_expression);

[CyrusNajmabadi]

Yes. This can always happen. The natural type can be different in isolation versus what happens when there is a target type and the rules there (which might introduce errors)

[bernd5]

You may use target typed new: (Link)

FunctionWrapper<string> funcWrapper2 = new (() => "hello");

[333fred]

I really don't expect any kind of information loss regarding the initial type of the expression.

No information loss occurs. To answer the original questions about behavior, we need to talk about two things: function type + standard implicit conversions, and delegate typing.

First, let's look at FunctionWrapper<string> funcWrapper2 = () => "hello";. As you pointed out, this does not work, because we intentionally limited where function type conversions (ie, from () => "hello" to Func<string>) can be observed:

Function_type conversions are not implicit or explicit standard conversions §10.4 and are not considered when determining whether a user-defined conversion operator is applicable to an anonymous function or method group. From evaluation of user defined conversions §10.5.3:

So, what is a standard conversion? A standard conversion is a conversion that occur on the input or output of a user-defined conversion (among a couple of other things that we don't care about here). The full set of conversion you're looking for here is: lambda expression -(1)> Func<Output> -(2)> FunctionWrapper<Output>, where 1 is a function type conversion, and 2 is a user-defined conversion. Function type conversions cannot be input to a user defined conversion, so this cannot occur all at once. Instead, you have to be explicit with the steps, by breaking out 1 into a separate assignment.

Second, let's look at the ref example:

        var delegateLambda = (ref string input) => { input = input + input; };
        DoStuffDelegate<string> delegWrapper1 = delegateLambda;

Again, this does not work, and this is where we need to talk about delegate typing. Delegates are nominally typed in C#, not structurally, as they are in some other languages. This means that delegate void MyAction(); is not convertible to Action, no matter that they have the exact same input and return types. The compiler tries to use Action and Func where it can for inferred delegate types, but sometimes it cannot make that work, as in this example. Action<string> does not take a parameter by ref, and there's no target type the compiler can use to inform what it should convert the lambda to, so the compiler needs create a new type for the lambda. This is a delegate type embedded into your assembly, which effectively looks like delegate void RefAction<T>(ref T t);, except that the name isn't speakable in C# code. Just like MyAction and Action cannot be converted between each other, RefAction and DoStuffDelegate cannot be converted between each other. When you do the assignment in a single line, the compiler can directly use the target (where the lambda is being assigned to) to convert the lambda into the delegate type requested, without needing to create RefAction at all.

[huoyaoyuan]

// if we do a single assignment... 
// ... it compiles
// but if type is inferred...

This is not the case. There are many situations where single assignment can't be splitted with var:

• Some expressions can't be used with var, for example the null literal.
• Some expressions have a natural type, but can be target-typed to another type, for example numbers (int vs short/byte) and stackalloc (pointer vs span).
• Some expressions were oringinally only target-typed. Default type introduced, but only one compatible type. Lambdas and upcoming collection literals are the case.