Question

What value do you think named and default parameters will add in C#.Net 4.0?

What would be a good use for these (that hasn’t already been achieved with overloading and overriding)?

Answer 1

It can make constructors simpler, especially for immutable types (which are important for threading) – see here for a full discussion. Not as nice as it should be perhaps, but nicer than having lots of overloads. You obviously can’t use object initializers with immutable objects, so the usual:

new Foo {Id = 25, Name = 'Fred'} 

isn’t available; I’ll settle for:

new Foo (Id: 25, Name: 'Fred') 

This can be extended to the general idea of simplifying overloads, but in most cases I’d prefer overloads that advertise the legal combinations. Constructors are a bit different, IMO, since you are just (typically) defining the initial state.

The COM side of things is also important to a lot of people, but I simply don’t use much COM interop – so this isn’t as important to me.

---

Edit re comments; why didn’t they just use the same syntax that attributes use? Simple – it can be ambiguous with other members / variables (which isn’t an issue with attributes); take the example:

[XmlElement('foo', Namespace = 'bar')] 

which uses one regular parameter (to the ctor, ‘foo’), and one named assignment. So suppose we use this for regular named arguments:

SomeMethod('foo', SecondArg = 'bar'); 

(which could also be a constructor; I’ve used a method for simplicity)

Now… what if we have a variable or a property called SecondArg? This would be ambiguous between using SecondArg as a named argument to SomeMethod, and assigning ‘bar’ to SecondArg, and passing ‘bar’ as a regular argument.

To illustrate, this is legal in C# 3.0:

    static void SomeMethod(string x, string y) { }     static void Main()     {         string SecondArg;         SomeMethod('foo', SecondArg = 'bar');     } 

Obviously, SecondArg could be a property, field, varialble, etc…

The alternative syntax doesn’t have this ambiguity.

---

Edit – this section by 280Z28: Sorry for adding this here, but it’s not really a unique answer and it’s too long for the comments and includes code. You hinted at the ambiguity but your example didn’t highlight the deciding case. I think the example you gave points out something that could be confusing, but the required {} around object initializers prevents an underlying syntactical ambiguity. My explanation for the following code is embedded as the multi-line block comment.

[AttributeUsage(AttributeTargets.Class)] public sealed class SomeAttribute : Attribute {     public SomeAttribute() { }      public SomeAttribute(int SomeVariable)     {         this.SomeVariable = SomeVariable;     }      public int SomeVariable     {         get;         set;     } }  /* Here's the true ambiguity: When you add an attribute, and only in this case  * there would be no way without a new syntax to use named arguments with attributes.  * This is a particular problem because attributes are a prime candidate for  * constructor simplification for immutable data types.  */  // This calls the constructor with 1 arg [Some(SomeVariable: 3)] // This calls the constructor with 0 args, followed by setting a property [Some(SomeVariable = 3)] public class SomeClass { } 

---