Is static lambda really static?

[kefyru]

     Func<int,int> f = static i => i;
     Console.WriteLine(f.Method.IsStatic) // -> false !!!

Is it necessary to use 'static' keyword, or compiler can resolve it from lambda body?

[stephentoub]

The static keyword when applied to a lambda has zero impact on the generated code. It serves only to enforce that the body of the lambda doesn't close over non-static state. Whether the emmitted method for the lambda is actually an instance or static method is an implementation detail of the C# compiler, and as you saw, your code today will result in an instance method (for performance reasons).

[colejohnson66]

As the author of closure conversion, I feel compelled to remind everyone: using reflection on delegates produced by lambdas (i.e., retrieving the MethodInfo via .Method) is explicitly compiler-defined behavior and you are not guaranteed any specific results or stability. Depending on this behavior is prohibited by the C# language specification.

What's the logic behind attaching an "instance" to static lambdas? I've seen it mentioned a few times that it's for performance reasons, but I haven't found a good explanation of why.

[colejohnson66]

Cool, so now as static isn't about instance anymore and only about scope, we can use static classes as generic parameter

Yes. This is something we're discussing. Especially since it would make sense for a static class to implement an interface with just static abstract methods.

Is there any update on this? I actually ran into this problem over the weekend trying to do something like public static class AddCarry : IGenericAluOperations in an emulator, but was told that static classes can't have "extends" lists (seems to be Rider's own message for CS0714). Removing static made Rider complain about a non-instantiated class.

[OwnageIsMagic]

@colejohnson66 https://stackoverflow.com/a/77004189/5647513

[colejohnson66]

@OwnageIsMagic Again, I understand it's for performance reasons, but I've yet to see why. "Performance" is not an answer.

[tannergooding]

delegates are types that wrap a function pointer and may track an associated instance. To invoke a delegate, you literally call an instance method named Invoke(...)

Since Invoke(...) is (and must be) an instance method so that it can access the function pointer and tracked state, this means there is a hidden first this parameter.

Thus, for a delegate bound to an instance method, it can simply replace the this parameter that's already been passed with the underlying tracked instance the delegate was bound against.

While for a static method, it means all the arguments are positionally "off by one" and need to be shuffled around (often swapping registers, potentially spilling or copying memory, etc). This "fixup" isn't exactly expensive, but it isn't free either.

Thus, using instance methods is functionally invisible to the user (it's an implementation detail of the emitted IL) and avoids the performance penalty that fixing up the signature to match ABI requirements would otherwise cause.