What language decision in C# annoys you?

Question

I was just dealing with strings, and I find myself annoyed that strings can be nullable. So, I have to have

if((teststring??string.Empty)==string.Empty)

all over the place. Would string? have been so hard for allowing nullability in the relatively few cases where it is needed (dbs, idiot user inputs, etc.). I also find myself irritated with having to export readonly interfaces in the cases where I want some form of const correctness. So, what C# language construct/decision annoys you?

EDIT: Thanks for the isnullorempty function, I hadn't seen that before! Still doesn't lessen my annoyance at it being nullable :D

Answer 1

Testing strings for Null or Empty is best done using:

if (string.IsNullOrEmpty(testString))
{
}

Answer 2

Making string a reference type seems entirely reasonable to me.

It's a shame that one can't declare a variable/parameter/return type to be non-nullable though - e.g.

// Never returns null
public string! Foo()
{
}

Code contracts in .NET 4.0 will help with this, I believe - but it's a bit late to make it pervasive.

A while ago I wrote a blog entry on the mistakes of C#. To summarise that post:

C# 1:

• Lack of separate getter/setter access for properties.
• Lack of generics. Life would have been a lot sweeter with generics from the start.
• Classes not being sealed by default.
• Enums just being named numbers.
• The "\x" character escape sequence.
• Various things about the switch statement :)
• Some odd overload resolution rules
• The "lock" keyword, instead of "using" with a lock tocken.

C# 2:

• Lack of partial methods (came in C# 3)
• Lack of generic variance (coming in C# 4)
• The System.Nullable class (not Nullable<T> - that's fine!)
• InternalsVisibleTo requiring the whole public key for strongly signed assemblies instead of the public key token.

C# 3:

• Lack of support for immutability - lots of changes improved opportunities for mutating types (automatic properties, object and collection initializers) but none of these really work for mutable types
• Extension method discovery

Answer 3

Probably the biggest glaring hole in C# is, for me, enums.

Java enums are typesafe classes that you can give behaviour to, can implement interfaces and so on.

C#/.Net enums are just glorified ints with all the problems int constants have had going back to C and C++.

Answer 4

out and ref parameters

Answer 5

Expanding on Mitch's answer.

That is actually a CLR decision, not a C# one. C# has no control over the implementation details of the BCL's System.String class.

True C# could have special cased string in the compiler and said we'll do special null checks but that would have IMHO, been a bad decision. String.IsNullOrEmpty is an acceptable compromise.

Answer 6

Enforcement of break in a non-empty case.

Verbosity of enums, especially in case statements. If I have switch (expr) and expr is an enum, I shouldn't be forced to fully qualify each enum in each case, unless there is a naming conflict.

Answer 7

Checked exceptions would have been great. I know a lot of people hate them from Java, but I think it's always enforced sanity checks, especially on I/O. I like most of the things that C# changed and/or added compared to Java, but I really would have liked them to have adopted checked exceptions. It's too late now (the .NET framework being changed to have them would break virtually every program out there) but I think it would have been better to have them.

Answer 8

The way I have to implement properties from an interface in c# 3.0 even though they are exactly the same as the interface when I'm not changing default behaviour of auto properties.

e.g.

public interface MyInterface
{
   int MyProperty { get; set;}
}

public class MyClass : MyInterface
{
   public int MyProperty { get; set; }
}

public class MyClass2 : MyInterface
{
   public int MyProperty { get; set; }
}

public class MyClass3 : MyInterface
{
   public int MyProperty { get; set; }
}

EDIT: To address some of the comments on this. I'm not changing any default behaviour of my getter. I understand the difference between class and interface thankyou, my point is that my marking it with the interface I shouldn't have to have this property inside every implementing class unless I want to change the default behaviour of the getter or setter. Imagine 500 classes implement this interface?

Also the lack of Mixins..

Answer 9

Not allowing co/contra-variance or access rights changes when overriding base class or implementing interface methods:

public class A
{
    protected virtual Stream method()
    {
        //...stuff...
    }
}

public class B : A
{
    // compiler borks...
    public override FileStream method()
    {
        //...more stuff...
    }
}

Answer 10

I hate having to type IEnumerable<MyType> all over the place. It is so hard to read. I would prefer some sort of short hand for it to make my code cleaner.

This SO post sums it up nicely.

Answer 11

I find it enormously irritating that so many core methods are static, especially around commonly used stuff like Strings and Arrays.

Why:

Array.Sort(myArray);
String.IsNullOrEmpty(myString);

instead of:

myArray.Sort();
myString.IsNullOrEmpty

Not saying there aren't good reasons for it and it's not a big deal, but if JS can manage it, why can't C#? *

Also the switch implementation. I really think they should have trusted us with fallthrough.

* Come to that I miss JS's closure syntax too.

Answer 12

I don't like IDisposable/Dispose etc. Coming from C++ it is very annoying to find yourself having to think about memory management in C#. The using statement is fine if the disposable object is only used in one function. If it has to be passed around you need to manually reference count or do something else to to know when you can dispose the object.

Answer 13

I'd like to see class objects as first class objects in the language.

This would allow you to override static methods, and declare them in interfaces.