Tuesday, February 05, 2008

C# 4, part 1: Looking back at the past

by skeet via Jon Skeet's Coding Blog : C# on 2/5/2008 7:45:13 PM

Everyone else is speculating about what's going to be in C# 4 (and various possibilities are coming out of MS), so I thought it would be wise to start my own series of wishlist posts before I miss the boat completely.

In this first post, I'm not going to look at the future at all - I'm going to look at mistakes of the past. When I say "mistake" I of course mean "things I would have done differently had I been a language designer with 20/20 hindsight". Of course, there's a lot of room for argument :)

Mistakes in C# 1

• Lack of separate getter/setter access for properties. This came in C# 2, but it should have been obvious that it was highly desirable long before C# 1 came out.
• Lack of generics - ish. Don't worry, I'm not going to claim that all the features of C# 2 and 3 should have been in C# 1, but if generics had been in at the start we could have avoided having the non-generic collections (and interfaces) completely. Mind you, I'm glad that the .NET team took their time instead of including the bodged (IMO) generics of Java 5.
• Classes not being sealed by default. I've believed for a long time that allowing inheritance incurs a design cost (and it's not like I'm unique in that respect). C# fixed a mistake of Java by making methods non-virtual by default; the same should be true for classes in my view.
• Enums just being named numbers. Again, I've blogged about this before, but it's worth mentioning again. It's possible -to work around the lack of this feature (as the blog post readers pointed out!) but framework and language support would have been very welcome.
• The "\x" character escape sequence. Fortunately it's rarely used, but it's so error-prone. Quick, how different are "\x8Good compiler", "\x8Bad compiler"? What's the first character in each string? (This will appear soon on my brainteasers page).
• The switch statement. There are lots of ways in which this could have been better designed. VB addresses some of them (such as making it easier to express multiple matching values) but there are other ways in which this construct needed overhauling. Fallthrough is (rightly) prohibited, so why not just force braces round the code in the case block instead of requiring a break statement? Aside from anything else, that would fix the somewhat bizarre scoping rules.
• Wacky overload resolution. I entirely understand the point that introducing new methods in a base type shouldn't change the behaviour in derived types - but if you've explicitly chosen to override that method, that should be more easily callable than it is. (See the first example of the brainteasers page to see what I'm talking about.)
• The "lock" keyword, and associated issues. Basically, the IDisposable pattern should have been used for locking, and not every object should have a monitor associated with it. Developers should keep a close eye on what's being locked, and being able to lock on everything takes away from this. Likewise "lock" creates a keyword for little purpose (and one which would otherwise be useful as a variable name etc).

Mistakes in C# 2

• Lack of partial methods. I'm really only saying this because it broke the format of C# in Depth slightly. I've introduced partial methods along with partial types because they logically fit in with them, and they don't fit in with any of the other features of C# 3 particularly. This is just a matter of not working out all of how partial types would be used - or at least not doing so early enough. (For all I know partial methods were on the table before C# 2 shipped - I wouldn't be surprised.)
• Possibly the lack of generic variance. This is certainly a big issue of understanding which is often raised as a question. On the other hand, I suspect that if/when it becomes available, it will raise just as many questions in terms of the detail anyway...
• The System.Nullable class. It's really only there as an historical accident, and I know it's not a C# issue as such - but even so... (Note for extra clarity - I'm fine with nullable types and the System.Nullable<T> struct. It's just the supporting class that I don't like.)
  
• InternalsVisibleTo requiring the whole public key for strongly signed assemblies instead of the public key token (contrary to the documentation). Ick.

Mistakes in C# 3

• It's a real shame that readonly automatic properties aren't in C# 3. I suspect they'll come in C# 4 (and they'll be on my wishlist in future posts) but I think it's reasonable to wonder why they weren't included in C# 3. Immutability is a known pattern of goodness, and although C# 4 may well contain any number of more significant improvements towards making it easier, readonly automatic properties would have been a good start.
• The way that extension methods are found. This issue was raised time and time again before release, and I've never heard a good defence of finding them by whole namespace, instead of allowing developers to say "use the extension methods found in this class, please". As it is, anyone writing their own extension methods is likely to end up with whole namespaces devoted to a single type. It's very odd.

Of course that's not to say there aren't other things I'd like to see - but these are more "features which were slightly misdesigned" rather than "features which I really want".

I'm not trying to take anything away from the language designers - C# is still easily my favourite language in terms of its design, particularly in C# 3, but nobody's perfect :)

Next time I'll start giving my opinions of features that other people are calling for.