I’m glad that the style suits you. Though I would argue that it is a direct violation of the Liskov substitution principle. Just imagine:

var myVariable = Api.GetMyVariable();
var myMethodResult = myVariable.GetResult();

And GetResult() being defined in IMyVariable as GetResult(int test = 2) and in MyVariable as GetResult(int test = 1)

Now the Api.GetMyVariable() changes from IMyVariable GetMyVariable() to MyVariable GetMyVariable() which is a valid substitution.
Unfortunatelly your var myMethodResult = myVariable.GetResult(); now changes its meaning without you even noticing.

Fun!

Like any other feature, as long as you know what is really happening, it makes sense. Default values are only there for convenience and the default you get will be exactly the default you know about at compile time (the default as declared on the variable type you are calling upon). This also means that intellisense will be able to let you know what value is is substituting as the default for you.

For the same reason if you had the following, you would not be able to use optional parameters on Derived2.Test, even though Base.Test supports it:

public class Derived2 : Base
{
public override string Test(int test)
{
return “Derived ” + test.ToString();
}
}

So I tried the same code in C++, and surprisingly (or maybe not), the behavior is exactly the same as C# 4 in CTP. Is this a tradition or something…

Cheers,
- RednaxelaFX (Kris Mok)

good call, trying out the VB version. And it makes more sense when looking at the VB implementation of the feature. That does get rid of a lot of the problems. Maybe since we are looking at the CTP of C# 4.0 they will “fix” it down the line.

Cheers,
Tobi

This does look terrible to me. Having known that VB.NET has had the optional parameter feature for a long time, I decided to try the same piece of code in VB.NET and see what happens. Darn, I just don’t know enough VB to get it right for the first time.

Class Derived
    Inherits Base
    Public Overrides Function Test( Optional t As Integer = 1 ) As String
        Return “Derived ” + t.ToString()
    End Function
End Class

Class Base
    Implements IBase
    Public Overridable Function Test( Optional t As Integer = 1 ) As String Implements IBase.Test
        Return “Base ” + t.ToString()
    End Function
End Class

Interface IBase
    Function Test( Optional t As Integer = 1 ) As String
End Interface

Module Program
    Sub Main()
        Dim b As Base = New Base()
        System.Console.WriteLine( b.Test() )
        Dim bi As IBase = b
        System.Console.WriteLine( bi.Test() )
        Dim d As Derived = New Derived()
        System.Console.WriteLine( d.Test() )
        Dim d2 As Base = d
        System.Console.WriteLine( d2.Test() )
        Dim d2i As IBase = d2
        System.Console.WriteLine( d2i.Test() )
    End Sub
End Module

VB.NET’s compiler will complain if the default values of optional parameters don’t match, which eliminates the problem you had in the C# 4 code. But then of course, you won’t be able to use different default values in the inheritance chain, which might be bad, or good, depends on what you’re trying to do.
Not sure whether creating a compiler flag for optional parameters is a good idea. Maybe for safety sakes we should suggest C# 4′s optional parameters to behave similiar to VB.NET’s…

- RednaxelaFX (Kris Mok)