¿Cuál es el razonamiento para que C# no admita argumentos opcionales/predeterminados?

Question

Anhelo esos dulces argumentos opcionales de los días en que programé más en C++. Sé que no existen en C#, pero mi pregunta es Por qué.

Creo que la sobrecarga de métodos es un mal sustituto que hace que las cosas se compliquen muy rápido.

void foo(int x,int y,int z=0){ 
    //do stuff... 
} 

//is so much more clean than 

void foo(int x,int y){ 
    foo(x,y,0); 
} 
void foo(int x,int y,int z){ 
//do stuff 
} 

Simplemente no entiendo cuál es el razonamiento. El compilador de C# obviamente no tendría problemas para respaldar esto, solo Microsoft eligió no admitirlo.

¿Por qué, cuando se diseñó C#, no querían admitir argumentos opcionales?

Answer 1

Como dice Andrey, C# 4 tiene los parámetros opcionales y con los argumentos nombrados. Sin embargo, vale la pena señalar que una de las preocupaciones que hizo Anders reacio a incluirlos para empezar, es decir, que el valor predeterminado (que tiene que ser una constante) se hornea en el llamando al código - todavía está presente. En otras palabras, es el mismo problema que los valores públicamente accesibles const de C# 1.

Answer 2

Creo que es inútil intentar responder la pregunta "¿Por qué?". Pero tengo buenas noticias, C# 4.0 los tiene.

Answer 3

Los argumentos opcionales no son tan simples como parecen. Es posible que tenga problemas complejos si tiene métodos sobrecargados que tienen argumentos opcionales. Las reglas de resolución pueden volverse muy complicadas muy rápidamente. Supongo que para la primera versión de C# no había una buena solución, así que omitieron los parámetros opcionales.

Pero probablemente sepa que C# 4.0 tendrá argumentos opcionales y con nombre, por lo que parece no ser una mala idea en general. ;-)

Answer 4

Aún no está allí, pero está en C# 4. Esto tiene que ver principalmente con el costo y qué tan bien encaja la característica con el principales partes nuevas del lenguaje (como Generics en .Net 2 o linq en 3). Los argumentos opcionales encajan con las novedades dinámicas que vienen en la versión 4, por lo que se han incluido.

Para citar Eric Lippert (¿Quién fue el propio citando Eric Gunnerson) sobre por qué muchos aparentemente buenas características no están incluidos:

(1) esto no es un proceso sustractivo; no comenzamos con C++, Java o Haskell y luego decidimos dejar alguna característica de ellos. Y (2) simplemente ser una buena característica no es suficiente. Las características tienen que ser tan atractivas que valgan los enormes costos en dólares de diseñar, implementar, probar, documentar y enviar la función. Tienen que valer la pena el costo de complicar el idioma y hacer que sea más difícil diseñar otras funciones en el futuro.