I'm not usually one for causal dismissals but that made me cringe. What on earth is the use case for getting rid of that tiny bit of boilerplate, relative to the complexity it adds to the language definition, that makes it worthwhile?
- declare a namespace for the file (no indentation)
- declare that the file is a class and can only contain one (top level) class (still no indentation)
- `using` statements that don't import every symbol into my namespace :
using System.Console;
...
Console.WriteLine();
using Sytem;
...
Console.WriteLine(); // where does "Console" come from ? god/IDE only knows
But alreay with these few changes, I've saved 10% of the 80 columns width. I've made it easy to read a file without an IDE. You can start to write actual code at indentation level 0. I've made it easy to have one class per file and hard to have two class per file, in the spirit of making good pratice easy and bad practice hard.
It doesn't solve the fundamental issue, but it definitely makes things clearer for me.
using Console = System.Console;Yes you can do `using Whatever = System.Console;`, fantastic, that's not the common idiom and it is harder to do (longer to write) than the usual idiom.
Can you open a text editor and get going with C#? Now you easily can. iPython and python notebooks gained lots of traction from just this type of simplicity.
If you were to write a "script" using the language, doing some things just top level is simple. Very pragmatic. I ALSO like that it's an error to call to any top level functions outside of this, so it keeps this from exploding complexity everywhere.
And I used to primarily work in scripting languages like Ruby where you'd get this 'feature' out of the box (although usually ended up writing a 'Program' class and a constructor/main method anyway for the scoping)