Static anonymous functions

[sharpzilla]

Can someone explain to me why I might need to write static in anonymous functions?

I've read several sources, such as:
Static anonymous functions in C# 9
Discussion on GitHub

And I got even more confused.

From what I understand, adding static in anonymous functions does not guarantee that the compiler-generated class will have a static method.

If I write code like this and don’t add the static keyword, the generated code will be identical to what it would have been if I had written static.
User code:

using System;

public class C {
    public void M() {
        Func<int, int> func = x => x * x;
        Func<int, int> funcStatic = static y => y * y;
    }
}

Compiler generated

public class C
{
    [Serializable]
    [CompilerGenerated]
    private sealed class PrivateC
    {
        public static readonly PrivateC PublicStaticReadonlyField = new PrivateC();

        public static Func<int, int> PublicStaticFieldX;
	public static Func<int, int> PublicStaticFieldY;

        internal int InternalMethodX(int x)
        {
            return x * x;
        }

        internal int InternalMethodY(int y)
        {
            return y * y;
        }
    }

    public void M()
    {
        Func<int, int> func = PrivateC.PublicStaticFieldX ?? (PrivateC.PublicStaticFieldX = new Func<int, int>(PrivateC.PublicStaticReadonlyField.InternalMethodX));
		
	Func<int, int> func2 = PrivateC.PublicStaticFieldY ?? (PrivateC.PublicStaticFieldY = new Func<int, int>(PrivateC.PublicStaticReadonlyField.InternalMethodY));

    }
}

What the static keyword definitely allows is highlighting at compile time when a local variable from the method context is captured in the anonymous function.

But now, instead of a concise lambda expression, I also have to write static before it, and the code starts to get bloated. What’s the point of using the static keyword if the output is identical?

The only advantage I can see from using static is the compiler hint. But along with that, I have to write more code compared to the approach where I don’t use the static keyword. I can’t fully trust the compiler and IDE to ensure there is no context capture. Let me explain why I think so. There are CodeFixers that will add static throughout the project for me, but when I look at a lambda expression that’s longer than y => y * y, I can’t be sure whether the person who wrote it deliberately didn’t use static because there’s a variable capture in the body of the expression, or if they simply forgot to add it. So I still end up scanning with my eyes to check if there’s context capture.

Of course, I can spend time writing static and quickly see the results from the code analyzer. But it seems like this doesn’t simplify my life at all.

If static isn’t used consistently throughout the project, it seems to lose its purpose, and I still have to manually analyze each lambda expression. There’s no unified convention in the project. For instance, if I’m using Entity Framework Core Fluent API to configure tables, the code becomes cluttered with static this or static that. I have to visually search for the actual essence of the code.

Am I missing some details that make using static in lambda expressions useful?

[huoyaoyuan]

The total point is to disallow capture for the given lambda. It's more a hint about other readers that "this is performance sensitive, capturing is not allowed". If you are not writing such performance sensitive code, you can simply ignore this feature.

[sharpzilla]

I understand that this can be used as a hint for other developers. However, I find it hard to imagine a situation where it could be applied. Let’s assume the following scenarios:

I write an anonymous function that currently does not capture the context. As I understand, the compiler’s output will be the same whether I use the static keyword or not.
1. I do not use static. Time passes, another developer comes along, and they need to make changes to the method logic. Now a variable needs to be passed into the body, causing context capture. The code compiles, but performance issues may arise because the private class now contains non-static methods.
2. I used static, explicitly telling everyone, "Hey, this is high-performance code." But later, the same developer wants to make changes, and context capture occurs. What should they do? They remove static, and the code works as required by new business requirements. Am I missing any details here about how to solve the problem of context capture without changing the lambda expression?

[huoyaoyuan]

But later, the same developer wants to make changes, and context capture occurs. What should they do? They remove static, and the code works as required by new business requirements.

Capture should be not used in business requirement and removing static is not allowed. They must find other way to satisfy the performance requirement. Typically, there can be other parameters to pass arguments without creating closures.

[En3Tho]

Yeah its weird to link "static" with "business requirements". These concepts are at way to different levels to matter to each other.

If you were writing a performance sensitive piece of code and cared about allocations (or rather their absence) you would simply use statuc there just to make sure you don't create a closure yourself. Then you obviously add a note to other people how the wholw thing works and why it has to be fast and written this way etc.

If you're asking such questions then it most probably means you've yet to write such code. Baeically, when the time and need comes you will understand.

[CyrusNajmabadi]

I understand that this can be used as a hint for other developers. However, I find it hard to imagine a situation where it could be applied. Let’s assume the following scenarios:

I write an anonymous function that currently does not capture the context. As I understand, the compiler’s output will be the same whether I use the static keyword or not.
1. I do not use static. Time passes, another developer comes along, and they need to make changes to the method logic. Now a variable needs to be passed into the body, causing context capture. The code compiles, but performance issues may arise because the private class now contains non-static methods.
2. I used static, explicitly telling everyone, "Hey, this is high-performance code." But later, the same developer wants to make changes, and context capture occurs. What should they do? They remove static, and the code works as required by new business requirements. Am I missing any details here about how to solve the problem of context capture without changing the lambda expression?

I was the author of this language feature. The point is that capturing can now not happen accidentally. It is blocked by the keyword. And if the developer removes the keyword that will be seen in the code review.

Contrast this with not having the keyword in the beginning. The code may not have captured and may have been very fast, but a user makes an innocuous chance that tanks that. But this change goes unnoticed because the lack of markers in the code.

This is not a hypothetical scenario. It happened to us numerous times in Roslyn itself. Fast lambda code that became slow and passed code reviews. static prevents that accident from happening.

It does not prevent intentional change from non capturing to capturing. It just makes that change apparent.