John Rusk asked me to elaborate on why I think static import is bad.

It's all about readability. Most people agree that the average line of source code is read far more times than it is written, which means that being able to understand the line is more important than being able to write it quickly.

Static import is bad because it adds an exception to the rules that everybody has to know and remember. If you see

int x = Process(s);

it's a line of code that's easy to understand, because you know what Process is, and more importantly, you know where to go look for it.

But if you add the capability of doing static imports, Process() can now come from other places, so you have to keep that in the back of your mind, and may have to traipse back to find the import statement. A good IDE could help out at this, but I don't think that should be a language design point.

One can argue that for its intended use - things like Math.Sin(), it will make things clearer, which I agree with. The problem is that I can see this feature being used by people who are familiar with their code to save time, and for them it's obvious that they've done that, but that's not true for the poor guy who inherits the code.

Any feature that comes with the kinds of warnings that were given at the introductions yesterday is questionable in my book, and I don't like adding something that has a good potential to be abused to address a case where people are doing the wrong thing already.

Of course, you can argue that C# has lots of areas of potential abuse, and I'd have to agree with you there, though I think the utility of those features is higher than merely saving a few keystrokes.