C# 4.0 Features – Named & Optional Parameters – Uh, no thanks.

Wednesday 19 May 2010 - Filed under Uncategorized

As always, the new version of C# comes packed with new features that are apparently supposed to make life easier. That was definitely the case with C# 3.0, adding support for concise lambda expressions, expression trees, local variable type inference, extension methods, and a few other good bits. (There was also a good pile of Absolute Garbage, such as SQL-like query comprehensions thrown in too, but I’m here to talk about new screw-ups, not old ones.)

Redmond seems to have missed the mark on 4.0 though. The vast majority of the added stuff seems poorly thought out or just plain not useful. First on the bashing list is the support for named and optional parameters in C#.

According to Microsoft, the main motivation for this was to ease COM interop. In case you didn’t already know, you need this junk because the Microsoft Office APIs are so horrendously awful and have 20 parameters on every function, most of which have to be set to the appropriate “missing” value for any sane use. This was apparently not a big deal when using a lame language like VB6, because instead of any sensible language features, they had added junk to cope with exactly this failure. VB.NET apparently got it too, but I’ve so far managed to avoid deeply learning that particular abomination.

So what’s wrong with named/optional parameters?

1. Default values are baked in at the call sites, so you can’t go back and change default values on public methods without recompiling every bit of dependent code. That’s a problem if you’re in the business of shipping libraries.
2. You can’t call a function that takes optional parameters from within a lambda which gets converted to an expression tree. Enjoy, a shiny new error message:
   

   CS0854: An expression tree may not contain a call or invocation that uses optional arguments

3. There’s a correct way to fix the Office API. That is, to issue a new API that has sane method signatures and generally doesn’t suck. Adding features to your language as a deodorant is doing it wrong.

I’ve never pined for optional parameters in C#. I hated the damn things in C++, and I see no reason why C# should be polluted with every godawful VB.NET misfeature, as seems to be current strategy. I also have no particular longing for named parameters – the IDE can already tell you the parameter names, doc comments, etc, so there’s no reason to pollute the source with them too. Again: if your API sucks so hard you need a language feature to paper over it, it’s your API that’s the problem.

One final comment: Insisting on feature parity between C# and VB.NET is batshit insane. Please. They are different languages. C# is the best language we have today for concisely GettingStuffDone. VB.NET allows a lot of morons to feed their families, and also keeps them out of my way – a similar role to Java. More seriously, let them evolve in different directions. Otherwise there’s no point in having two syntaxes, you’d be better off killing VB.NET.

2010-05-19  »  admin