Support runtime casting for types with dynamic as a generic parameter

[RenderMichael]

When using dynamic as a generic parameter for a given type, it seems natural that this can be slotted in for any other generic parameter on that type.

In current C#:

using System;
   
void M(Func<dynamic> dynamicAction)
{
    B(() => dynamicAction.Invoke()); // Works perfectly
    B(dynamicAction.Invoke); // error CS0407: 'dynamic Func<dynamic>.Invoke()' has the wrong return type
}

void B(Func<bool> s) => throw null;

For .NET 7, caching of methods was improved and IDE0200 (Remove unnecessary lambda expression) was introduced. For this reason, I tried adding this in my scenarios represented above, and received an error.

I know everyone hates dynamic. Adding functionality along these lines might bring more eyes on dynamic and tempt people to use it.

As someone who works with it at my company, I understand more than most. But this seems like a completely natural scenario we would love to use, for both code quality and whatever performance gain we can muster.

Edit: The original title talked about "covariance" between types like M and M, I was drawing a spiritual parallel but the new title better reflects the actual proposal.

[RenderMichael]

This error happens both with the "covariance" and "contravariance", switching Func<bool> and Func<dynamic> in the signatures returns the same error at the same point.

[CyrusNajmabadi]

For .NET 7, caching of methods was improved and IDE0200 (Remove unnecessary lambda expression) was introduced.

If we're offering the feature here that would be a bug. Bool and dynamic should not have a variance relationship.

[svick]

Variance in C# only works when the conversion "does nothing", i.e. the converted object is the same as the original one. When it comes to dynamic, that effectively means treating it the same as object. But that then means that the covariant conversion from e.g. Func<string> to Func<dynamic> works (because conversion from Func<string> to Func<object> works), but other kinds of conversions involving Func<T> won't work.

Specifically:

• Variant conversions can never involve value types, since treating a value type as object/dynamic requires boxing.
• The conversion from Func<dynamic> to e.g. Func<string> would be considered contravariant and so it doesn't work. (Even though an implicit conversion from dynamic to string exists.)

I don't see any of this changing.

[RenderMichael]

@CyrusNajmabadi @svick that's why I put "covariance" in quotes, I'm just talking about converting between MyMember<dynamic> <-> MyMember<otherType> the same way dynamic <-> otherType works. This isn't even a real conversion, just runtime type checking

[RenderMichael]

That just sounds like a runtime type mismatch, because the List<dynamic> that you new up isn't actually a List<int>.

Whereas if you had a List<dynamic> which was actually a List<int>. The correct version of that code would be

List<dynamic> list = new List<int>();
((List<int>)list).Add(42);

[RenderMichael]

I hadn't thought of your example, that definitely limits the conversion possibilities here. But that might actually help this feature's odds of getting accepted, since it probably means less scenarios to support. Maybe there could be limited conversion options? Or maybe, given the nature compiler errors when using dynamic, the list-casting scenario you brought up could simply be allowed to fail?

[svick]

That sounds less like dynamic and more like something like #1992. I.e. you would have a variable of type List<?>, which means it's a List<T> for some T.

[RenderMichael]

Wow, that's a neat proposal, and an intense discussion to read through.

It doesn't look like there's too much support among the team for it, nor does the scenario I have need such a complex solution. This proposal is intended to extend dynamic to what I see as a natural extension, with the same blasé attitude towards compile-time safety that dynamic has today.

[333fred]

But it doesn't have a blase approach, it has a very principled approach. Variance can only happen when the conversion is representation-preserving. A boxing or unboxing conversion (as happens in the B(() => dynamicAction.Invoke()); example from your OP) is not representation preserving. Looking at a more complete example:

M(() => true); // Boxing conversion to object (ie, dynamic) occurs in the body of this lambda
   
void M(Func<dynamic> dynamicAction)
{
    B(Local);
    
    bool Local() => dynamicAction.Invoke(); // A call to the DLR to typecheck and unbox the result of the Func<dynamic> invocation occurs in the body of this method.
}

void B(Func<bool> s) => Console.WriteLine(s()); // No dynamic action occurs in the body of this method, only in the body of the delegate passed to B.

Here, the () => true; lambda has a box emitted, moving the true constant to an object box on the heap. Then, the implementation of Local (IL pasted below) needs to emit the dynamic code to actually call the DLR and do the unboxing conversion if the input is actually a bool (the Convert call in the code below). These actions are not representation preserving: the value returned by the Func<dynamic> needs to be massaged before it can be used as bool. Converting from Func<dynamic> to Func<string> is more plausible, given that the reverse is possible today, but still quite complicated, as the DLR will have to be able to do that nested type check where it can't today. But since the boxing/unboxing conversion in your original example cannot be representation preserving, it is not a candidate for variance (in the .NET CLR as it exists today, anyway. You could certainly design a VM that has magic behind the scenes to allow for representation-changing variance, but the rabbit hole that enters very quickly becomes overwhelming in complexity).

        .method assembly hidebysig 
            instance bool '<<Main>$>g__Local|3' () cil managed 
        {
            // Method begins at RVA 0x210c
            // Code size 75 (0x4b)
            .maxstack 3

            IL_0000: ldsfld class [System.Linq.Expressions]System.Runtime.CompilerServices.CallSite`1<class [System.Runtime]System.Func`3<class [System.Linq.Expressions]System.Runtime.CompilerServices.CallSite, object, bool>> Program/'<>o__0'::'<>p__0'
            IL_0005: brtrue.s IL_002b

            IL_0007: ldc.i4.0
            IL_0008: ldtoken [System.Runtime]System.Boolean
            IL_000d: call class [System.Runtime]System.Type [System.Runtime]System.Type::GetTypeFromHandle(valuetype [System.Runtime]System.RuntimeTypeHandle)
            IL_0012: ldtoken Program
            IL_0017: call class [System.Runtime]System.Type [System.Runtime]System.Type::GetTypeFromHandle(valuetype [System.Runtime]System.RuntimeTypeHandle)
            IL_001c: call class [System.Linq.Expressions]System.Runtime.CompilerServices.CallSiteBinder [Microsoft.CSharp]Microsoft.CSharp.RuntimeBinder.Binder::Convert(valuetype [Microsoft.CSharp]Microsoft.CSharp.RuntimeBinder.CSharpBinderFlags, class [System.Runtime]System.Type, class [System.Runtime]System.Type)
            IL_0021: call class [System.Linq.Expressions]System.Runtime.CompilerServices.CallSite`1<!0> class [System.Linq.Expressions]System.Runtime.CompilerServices.CallSite`1<class [System.Runtime]System.Func`3<class [System.Linq.Expressions]System.Runtime.CompilerServices.CallSite, object, bool>>::Create(class [System.Linq.Expressions]System.Runtime.CompilerServices.CallSiteBinder)
            IL_0026: stsfld class [System.Linq.Expressions]System.Runtime.CompilerServices.CallSite`1<class [System.Runtime]System.Func`3<class [System.Linq.Expressions]System.Runtime.CompilerServices.CallSite, object, bool>> Program/'<>o__0'::'<>p__0'

            IL_002b: ldsfld class [System.Linq.Expressions]System.Runtime.CompilerServices.CallSite`1<class [System.Runtime]System.Func`3<class [System.Linq.Expressions]System.Runtime.CompilerServices.CallSite, object, bool>> Program/'<>o__0'::'<>p__0'
            IL_0030: ldfld !0 class [System.Linq.Expressions]System.Runtime.CompilerServices.CallSite`1<class [System.Runtime]System.Func`3<class [System.Linq.Expressions]System.Runtime.CompilerServices.CallSite, object, bool>>::Target
            IL_0035: ldsfld class [System.Linq.Expressions]System.Runtime.CompilerServices.CallSite`1<class [System.Runtime]System.Func`3<class [System.Linq.Expressions]System.Runtime.CompilerServices.CallSite, object, bool>> Program/'<>o__0'::'<>p__0'
            IL_003a: ldarg.0
            IL_003b: ldfld class [System.Runtime]System.Func`1<object> Program/'<>c__DisplayClass0_0'::dynamicAction
            IL_0040: callvirt instance !0 class [System.Runtime]System.Func`1<object>::Invoke()
            IL_0045: callvirt instance !2 class [System.Runtime]System.Func`3<class [System.Linq.Expressions]System.Runtime.CompilerServices.CallSite, object, bool>::Invoke(!0, !1)
            IL_004a: ret
        } // end of method '<>c__DisplayClass0_0'::'<<Main>$>g__Local|3'