Why doesn't C# support local static variables

Question

Why doesn't C# have local static variables like C? I miss that!!

Answer 1

Because they screwed up, and left out a useful feature to suit themselves.

All the arguments about how you should code, and what's smart, and you should reconsider your way of life, are pompous defensive excuses.

Sure, C# is pure, and whatchamacallit-oriented. That's why they auto-generate persistent locals for lambda functions. It's all so complicated. I feel so dumb.

Loop scope static is useful and important in many cases.

Short, real answer, is you have to move local statics into class scope and live with class namespace pollution in C#. Take your complaint to city hall.

Answer 2

So you want to use a static local variable in your method? Congratulations! You made another step towards becoming a real programmer.

Don't listen to all the people telling you that static locals are not "clean", that they impede "readability" and could lead to subtle and hard-to-find "bugs". Nonsense! They just say that because they are wannabe programmers! Lots of them are probably even toying around with an esoteric functional programming language during their free-time. Can you believe it? What a bunch of hipsters!

Real programmers embrace a paradigm I like to call SDD - Side effect Driven Design. Here are some of it's most important laws:

Don't be predictable! Never return the same thing from a method twice - even if it's being called with the exact same arguments!

Screw purity - let's get dirty! State, by nature, craves changing, because it is an insatiable monoid in the category of polyamorous endofunctors, i.e. it likes to be touched by as many collaborators as possible. Never miss out on an opportunity to do it the favor!

Among the tools used to code in a side effect driven manner are, of course, static local variables. However, as you noticed, C# does not support them. Why? Because over the last two decades Microsoft has been infiltrated by so called Clean Coders that favor maintainability over flexibility and control. Can you even remember the last time you have seen our beloved blue screen? Now guess whose fault is that!

But fear not! Real developers don't have to suffer from those poor design decisions. As has been mentioned before it is possible to have local variables that are kind of static with the help of lambdas.

However, the provided solution wasn't quite satisfactory. Using the previous answer our almost-SDD-compliant code would look something like this:

var inc = Increment();
var zero = inc();
var one = inc();

or

var zero = Increment()();

But that's just silly. Even a wannabe developer can see that Increment() is not a normal method and will get suspicious. A real programmer, on the other hand, can make it even more SDD-like. He or she knows that we can make a property or field look like a method by giving it the type Func<T>! We just have to initialize it by executing a lambda that in turn initializes the counter and returns another lambda incrementing the captured counter!

Here it is in proper SDD code:

public Func<int> Increment = new Func<Func<int>>(() =>
{
    var num = 0;
    return () => num++;
}).Invoke();

(You think the above kinda looks like an IIFE? Yes, you are right and you should be ashamed of yourself.)

Now every time you call Increment() it will return something different:

var zero = Increment();
var one = Increment();

Of course you also can make it so that the counter survives the lifetime of your instance.

That'll show them wannabe programmers!

Answer 3

C# is a component-oriented language and doesn't have the concept of variables outside the scope of a class or local method. Variables within a method cannot be declared static either, as you may be accustomed to doing in C. However, you can always use a class static variable as a substitute.

As a general practice, there are usually ways to solve programming problems in C# without resorting to using method-level statics. State is generally something you should design into classes and types, not methods.

Answer 4

Logically, yes. It would be the same as a class-level static member that was only used in that one method. However, a method-level static member would be more encapsulated. If the data stored in a member is only meant to be used by a single method, it should only be accessible by that single method.

However, you CAN achieve almost exactly the same effect in C# by creating a nested class.

Answer 5

You can simulate it using a delegate... Here is my sample code:

public Func<int> Increment()
{
    int num = 0;
    return new Func<int>(() =>
    {
        return num++;
    });
}

You can call it like this:

 Func<int> inc = Increment();
 inc();

Answer 6

I'm not nearly as familiar with C as I am C#, but I believe you can accomplish everything you could with a local static, by using a class level static that is only used for one method. Obviously, this comes with some syntactic change, but I believe you can get whatever functionality you need.

Additionally, Eric Lippert answers questions like this on his blog a lot. Generally answered in this way: "I am asked "why doesn't C# implement feature X?" all the time. The answer is always the same: because no one ever designed, specified, implemented, tested, documented and shipped that feature." Essentially his answers generally boil down to, it costs money to add any feature, and therefore, many potential features are not implemented because they have not come out on the positive side of the cost benefit analysis.