Thank you for your explanations, but I'm not at all happy with it...

First, there are a lot of C# features which could be done another way, but we like C# because it offers already known features more elegant.
Second, threading as such is also 'somewhat notorious for causing problems' but that does not stop us using it. Additionally, it is not at all elegant to have class-level static variables which in fact belongs to a method. They get degraded to 'class global variables' and it's just a question of time until another developers misuse them and we will earn side effects.
Of course, it's possible to put such a method in it's own class, but I think we don't really have to discuss such 'solutions' here.

I'm sure, that static method variabls must be used carefully, but then, they make sense and are very useful.

kind regards,
Thomas
Schittli

I must agree with Thomas, especially when the C# team decided to add features such as partial types - don't you those are going to make finding definitions of anything a lot harder than method static variables? I hope those three reasons posted are not the actual reasons the C# design team based their decisions on.

As for method static variables being problematic when the method is called from multiple threads - how exactly are they different from class static members? From the implementation point of view they're class static members that are scoped to a single method.

I'm with the C# team on this one. A method itself doesn't logically have state outside the period during which it's being called. If you've got a method which has separate state, it should be a separate object - or the state should be part of the class.

I agree, I don't believe that a method should encapsulate data. That is the purpose of an object.

ironically vb.net supports them. Go figure.

It seems to me there are two angles of approach. The language designers are trying to follow a rationale that fits the principles underlying the language. Programmers are trying to do a job and know which features they find useful. The C# team have had a rare opportunity to design a language from scratch and are keen to keep it as ‘clean’ as possible. On the other hand the VB team are re-designing an existing language and, I suspect, are more likely to keep features which are arguably not ideal but serve a very useful purpose. The idea of a variable which is scoped to a method but retains its value between calls is very old and useful in certain circumstances. Enumeration is one which comes to mind. On balance, rather than write a whole class to do a single simple job, I would prefer to be able to do it in a single function.