Optional parameters are probably ok if you have 1 of them and you never have to change your output type for the method.
If you start to get more than that, your client code can start to get really ugly.
For instance, if a method/function has many optional parameters and in your call to it, you only want to change the very last one, you end up doing stuff like this:
* You put the default values in yourself to get to that parameter at the end you want to change (which defeats the purpose of having the default parameters in the first place). If you end up doing this, you have to bleed default value information into the client code that should only be in the method itself. Should you ever have to change the default parameter values in the method, you then have to hunt through all of the client code to change those as well .
* Sometimes the language lets you name the optional parameter variable and assign your value to that. This eliminates the above problem. However, you now have new issues. Should you want to rename your parameter variable, you have to hunt through client code again. In C#, if you start using some of the more OO-related concepts and structures such as interfaces and delegates, the method's "signature" is more important than variable names themselves. (Which is most likely the main reason why Java and C# opt for overloading rather than optionals.)
When C# was originally created, the designers behind it weren't terribly interested in "syntactical sugar" or VB6-ish behavior in the compiler. For example, C#'s implementation of generics is a truely type-safe version of it, as opposed to java's implementation which magically adds the appropriate casts to objects in the generated byte code.
C# today isn't really like that anymore. They're constantly adding short cut methods to the code parser (vars, lambda expressions vs. delegates, auto-properties, etc). I'd say optional parameters would be in that realm, so I wouldn't be surprised if it's implemented some day.
If you start to get more than that, your client code can start to get really ugly.
For instance, if a method/function has many optional parameters and in your call to it, you only want to change the very last one, you end up doing stuff like this:
* You put the default values in yourself to get to that parameter at the end you want to change (which defeats the purpose of having the default parameters in the first place). If you end up doing this, you have to bleed default value information into the client code that should only be in the method itself. Should you ever have to change the default parameter values in the method, you then have to hunt through all of the client code to change those as well .
* Sometimes the language lets you name the optional parameter variable and assign your value to that. This eliminates the above problem. However, you now have new issues. Should you want to rename your parameter variable, you have to hunt through client code again. In C#, if you start using some of the more OO-related concepts and structures such as interfaces and delegates, the method's "signature" is more important than variable names themselves. (Which is most likely the main reason why Java and C# opt for overloading rather than optionals.)
When C# was originally created, the designers behind it weren't terribly interested in "syntactical sugar" or VB6-ish behavior in the compiler. For example, C#'s implementation of generics is a truely type-safe version of it, as opposed to java's implementation which magically adds the appropriate casts to objects in the generated byte code.
C# today isn't really like that anymore. They're constantly adding short cut methods to the code parser (vars, lambda expressions vs. delegates, auto-properties, etc). I'd say optional parameters would be in that realm, so I wouldn't be surprised if it's implemented some day.