Missteps in the Design of the C# Language

C# as a language has many benefits over Java.  Some of the more noticeable include a proper implementation of generics, anonymous delegates and lambdas, and niceties such as the var keyword, IDisposable, and LINQ expressions.  However, there are several parts of the C# language that are poor, and would have been (are) easy to fix.

Enumerations

Why can I not add methods to enumerations as I can in Java?  The only time I use C# enumerations anymore is for DTOs.  Otherwise, I know from experience that I am going to end up with a switch statement on the enumeration when I should be using polymorphism.  See below:

enum Fruit { Apple, Orange }

vs.

class abstract Fruit
{
    public static readonly Fruit Apple = new Apple(1);
    public static readonly Fruit Orange = new Orange(2);

    protected Fruit(int id)
    {
        _id = id;
    }

    public int Id
    {
        get { return _id; }
    }

    public abstract virtual void Peel();

    private class Apple : Fruit
    {
        public Apple(int id) : base(id)
        {}

        public override void Peel()
        {
            // omitted for brevity
        }
    }
    // rest omitted for brevity
}

Events

Events are probably the worst offender.  Why is there an event keyword?  Why not just use the already existing multicast delegate?  Is not having to encapsulate the field really worth the confusion it causes?  Public events appear to be able to be referenced by outside classes.  This is however not the case, some methods can only be accessed by the owner class.  For even more fun try passing an event to a method.  Also why not use the null object pattern with events instead of forcing me to do this every time:

public event EventHandler ButtonPushed = delegate {};

An argument against this is that invoking a null event should result in a null reference because it was never allocated.  Well then why can I append to it?  I can't add an element to a null list reference, then why can I append an EventHandler to a null event?  The most consistent solution would be to require allocation before appending.

Structs

It is very useful to be able to allocate data on the stack.  Unfortunately if you have any references to classes, then your struct gets boxed and goes on the heap.  Structs should have been named value, so as not to confuse them with the unrelated C++ structs and to be more intention revealing.  Also the compiler should prevent you from referencing any classes, as to preserve the benefits of stack allocation.

// this shouldn't compile
struct Currency
{
    public int Dollars;
    public int Cents;
    public string Symbol;
}

// this should compile
value Currency
{
    public int Dollars;
    public int Cents;
}

Nullable<T>

A coworker introduced me to this one inspired by his learning of Haskell and the Maybe monad.  References to classes should be NOT nullable by default.  References to classes that can be null should be marked with a ?.  Imagine how useful it would be to know which variables could be null and the convention was enforced by the compiler?

public static void MethodToCall(RequiredArg reqArg, OptionalArg? optional);

// should not compile
MethodToCall(null, null);

// should compile
MethodToCall(new RequiredArg(), null);

While C# as a a language definitely has its benefits over Java, there are still some warts that could definitely be fixed.