Hi. I'm Jon Jagger.
I help software teams improve their effectiveness.
I built cyber-dojo, the place teams practice programming.
I'm based in the UK.
I've worked in 22 countries.
If you don't like my work, I won't invoice you.
Hire me

Pages

At the ACCU 2004 conference I gave a talk on the evolution and design of C#. During the talk I emphasized the explicit nature of C# software. It's rare (at least in C# 1.0) for the compiler to add code to what you've written. To take a simple example:
new int[4]{1,2,3};
is a compile time error in C#. The compiler does not append a default zero to the list. Another example is the virtual and override keywords:

Another example is how the ref and out keywords have to be placed on both the argument and the parameter. Lack of fall-through in a switch statement is another.
But there are some counter-examples.
Default visibility is internal and default accessibility is private. But note that static constructors, destructors, and explicit interface implementations of properties indexers and operations are not private by default. In those cases you can't specify an accessibility and they're not private since they can't even be called from sibling functions.
Here's another one. By default a class is not sealed. I find this surprising because inside the class the reverse is true - you have to explicitly use virtual/override keywords. Perhaps C# would benefit from an unsealed keyword (the checked/unchecked provide a precedent for paired keywords). Then all classes would have to be explicitly abstract, unsealed or sealed.

It seems to me there is an important distinction to be made between these kind of defaults (where there is a choice) and defaults where there is no choice (for example interface members must be implicitly public).