In C++, you can have a static variable defined in a function – scoped to the block, and with no linkage, but with a lifetime that extends from the first instantiation to the end of the program, unlike an auto. You’re not allowed this in C# – why not?
Well first of all, is it a good idea?
Static is one of the most overused and poorly understood keywords in the programming language ecosystem. In C++ alone it has at least five meanings – as a modifier affecting duration and linkage, orthogonally. It gets worse, because it was then co-opted to mean ‘determined at compile time rather than at runtime’.
In C++ static locals are commonly used as reference counters – initialise the counter once and increment it each time the function’s called. This can be replicated in C# by moving the static variable to class scope, but that feels like it breaks encapsulation.
Does it? No, it doesn’t. In OO, functions were never meant to contain data, only to expose and mutate it. A class or a struct is a container of data, so the class level is exactly the right place for your static.
Further, their use is actively dangerous, for reasons that aren’t immediately obvious. Functions with static locals are implemented with a hidden static boolean variable representing the initialisation state of the variable in question, as well as some simple code to check the state and instantiate it once. Predictably, this code itself isn’t thread safe. This issue is discussed at length in this codeguru article.
So, static locals aren’t really a very good idea in an OO environment, and also lull the unknowing developer into a false sense of security. Sounds like a bad candidate for a language feature to me!