C# Explictness

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:

class Wibble
{
    public virtual void Method() { ... }
}
class SpecializedWibble : Wibble
{
    public override void Method() { ... }
}

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.

unsealed class wibble
{
    ...
}
sealed class SpecializedWibble : Wibble
{
    ...
}

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).