Rationale for referencing object instance when instantiating delegates for static lambdas #51344
Unanswered
WizardBrony
asked this question in
Q&A
Replies: 1 comment
-
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. |
Beta Was this translation helpful? Give feedback.
0 replies
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
-
Consider the following C# class:
The IL generated for the body of
TestMethod1
will look something like the following:This makes sense: the compiler knows that
GetInt
is static, so it simply passesnull
when instantiating the delegate that gets passed toInvoke
.Now let's swap out
GetInt
for a lambda:The IL for
TestMethod1
will now look something like this: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?Beta Was this translation helpful? Give feedback.
All reactions