Rationale for referencing object instance when instantiating delegates for static lambdas #51344

WizardBrony · 2021-02-19T19:50:50Z

WizardBrony
Feb 19, 2021

Consider the following C# class:

[TestClass]
public class UnitTest1
{
    [TestMethod]
    public void TestMethod1() => Invoke(GetInt);

    private static int GetInt() => 5;

    private static void Invoke(Func<int> func) => func();
}

The IL generated for the body of TestMethod1 will look something like the following:

    // [8 34 - 8 48]
    IL_0000: ldnull
    IL_0001: ldftn        int32 UnitTest1::GetInt()
    IL_0007: newobj       instance void class [System.Runtime]System.Func`1<int32>::.ctor(object, native int)
    IL_000c: call         void UnitTest1::Invoke(class [System.Runtime]System.Func`1<int32>)
    IL_0011: ret

This makes sense: the compiler knows that GetInt is static, so it simply passes null when instantiating the delegate that gets passed to Invoke.

Now let's swap out GetInt for a lambda:

public void TestMethod1() => Invoke(static() => 5);

The IL for TestMethod1 will now look something like this:

    // [8 34 - 8 55]
    IL_0000: ldsfld       class [System.Runtime]System.Func`1<int32> UnitTest1/'<>c'::'<>9__0_0'
    IL_0005: dup
    IL_0006: brtrue.s     IL_001f
    IL_0008: pop
    IL_0009: ldsfld       class UnitTest1/'<>c' UnitTest1/'<>c'::'<>9'
    IL_000e: ldftn        instance int32 UnitTest1/'<>c'::'<TestMethod1>b__0_0'()
    IL_0014: newobj       instance void class [System.Runtime]System.Func`1<int32>::.ctor(object, native int)
    IL_0019: dup
    IL_001a: stsfld       class [System.Runtime]System.Func`1<int32> UnitTest1/'<>c'::'<>9__0_0'
    IL_001f: call         void UnitTest1::Invoke(class [System.Runtime]System.Func`1<int32>)
    IL_0024: ret

The compiler is generating a non-static class ('<>c') to represent the operation that the lambda describes, and it's instantiating a delegate that references an instance of that non-static class. But again, the compiler knows that the lambda is static, so what is the rationale for making both '<>c' and the method representing the lambda non-static?

CyrusNajmabadi · 2021-02-19T20:26:46Z

CyrusNajmabadi
Feb 19, 2021
Collaborator

I seem to recall we learned the runtime is actually faster here in the non-static case than in the static case. But my memory is ancient and coudl be totally wrong here.

0 replies

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Uh oh!

Rationale for referencing object instance when instantiating delegates for static lambdas #51344

Uh oh!

{{title}}

Uh oh!

Replies: 1 comment

Uh oh!

{{title}}

Uh oh!

Select a reply

Uh oh!

Rationale for referencing object instance when instantiating delegates for static lambdas #51344

Uh oh!

WizardBrony Feb 19, 2021

Replies: 1 comment

Uh oh!

CyrusNajmabadi Feb 19, 2021 Collaborator

WizardBrony
Feb 19, 2021

CyrusNajmabadi
Feb 19, 2021
Collaborator