C# 4.0 New Features Part 2 – default and named parameters

by Justin Etheredge on October 29, 2008

This post was migrated from Justin’s personal blog, 'Codethinked.com.' Views, opinions, and colorful expressions should be taken in context, and do not necessarily represent those of Simple Thread (and were written under the influence of dangerous levels of caffeination).

This next new features in C# 4.0 is one that I have been waiting on for years! And in the past it has always been explained away as an explicit design decision. Well, apparently pragmatism has won out and we now have default parameters in C#. In order to make default parameters even more useful, they threw in named parameters as a bonus! We will look at those in just a minute, but first, defaults.

Very nice. The third parameter in this call will be defaulted to 12.2, just like it was set that way. Now all of the VB.net developers can stop making fun of us. Now, you will also be happy to know that this works for constructors as well.

No more multiple constructor overloads to just specify a few default values.

So, what happens if we want to leave out "val2" in the call above? So, we want to fill in val1 (the first parameter) and we want to pass in val3 (the third parameters), but we want to default val2. We couldn’t call it like this:

That wouldn’t compile since 10.2 cannot be converted to an int, since it is trying to default the third parameter here. So what option do we have? We can use named parameters. Named parameters simply consist of putting the parameter name, and then a colon in from of the value you are passing. So the call above would look like this:

Kinda neat, although I’m not sure how I feel about the fact that this will now make changing a parameter name a breaking change. I guess only time will tell how this plays out in large application development. Although I’m sure that people in other languages have been dealing with this for years.

Well, there you have it, yet another cool new feature of C# 4.0 and yet anther reason to look forward to VS2010.

SHARE ON

10 Comments

Because of Visual Basic.NET, changing parameter names was [i]already[/i] a breaking change, so this isn’t a new issue, it just actually impacts you now…

I’m also not entirely fond of the default value implementation, as (from what I’ve heard) it follows the VB.NET model where the parameter value is "baked into" the caller’s code, meaning you can’t change the default value and have it impact existing code (which is the supposed reason for the lack of default values in C# 1.0).

There is a way to do both, though: have the compiler automagically generate the overloads, e.g. if you write:

void Foo (int a = 1) {}

the compiler would generate:

void Foo () {Foo (1);}
void Foo (int a) {}

It’s "magical," but the compiler [i]already[/i] performs lots of "magic" with anonymous delegates, types, and lambdas, and this would have the added benefit that you could change the constant value and existing code would get the new value (as current overloading allows)…

But this isn’t apparently how they chose to implement it, probably because compiler-generated overloads don’t solve the named-parameter problem (which is useful for COM interop)…

That is a completely awesome addition to the C# language. I just wonder with the evolution of the language whether the entry point for new developers is being set to overwhelming levels. C# and .NET are rapidly expanding that it could be a victim of its own power. I love it though, haha. Good Job!

This reminds me of VB4/5/6 with optional and default parameters. Although, I’m not sure that that makes it a bad thing. When I learned C# from a background in VB and discovered that the closest you could get was overloads and cascading invocations, I was disappointed. But I got over it. In like 5 minutes.

This is too good. Not too long ago, the c# purists were spitting upon this idea ( http://www.vbrad.com/article.aspx?id=65 ), e.g. it’s a hack, not oop enough, etc… Now, all of sudden, it’s cool. Enjoy the cool-aid.