VD>Вообще-то Kiguinko прав!
Я же сразу оговорился, что могу быть не прав. Мое заявление базируется на информации, полученной еще при выходе pre-beta версии. С того момента могло многое измениться.
VD>В доках есть раздел о дефолтных параметрах в C#, то реально облом!
Кстати, а где, если не секрет?

ЯГ>>Обусловлено это спецификой работы .NET. Две причины:
ЯГ>>1. Подставить параметр на вызываемой стороне нельзя, т.к. .NET, как и СОМ работает на интерфейсах, а интерфейс — контракт, в котором форма вызовов методов строго определена. Значит параметр нельзя опустить.

VD>По-моему Вы не правы. Уж точно Вы не правы насчет COM-а. В COM-ме есть дефолтные параметры.
Но они подставляются на вызывающей стороне, насколько я помню.
VD>Да и в CLR-ных языках сделать, это как рас плюнуть. Дело в том, что информацию о параметрах можно разместить в Reflection-информации (.Net-овском аналоге TLB-х).
Именно так это и делается в СОМ.

VD>Я и говорю... НЕ в рантайме, а при компиляции.
Во во. Ключевое слово тут "при компиляции". В то время MS считала, что в .NET не должно быть ничего, что можно сделать только при компиляции.

ЯГ>>... а значит, пропадает контроль за версиями. Как сообщить клиенту, что новая версия объекта в качестве параметра по умолчанию теперь ожидает не 1, а 2?

VD>Скомпилированная программа должна работать с теми предположениями (о значении дефолтных параметров) которые были верными на момент компиляции. Если это будет не так, то вероятность вылет будет 90%.
Я бы привел ссылку, но уже не помню. Давненько я не интересовался как дела у .NET, так что спорить не стану, все могло измениться. В той статье такое поведение объяснялось именно нарушением контроля версий.
Самым лучшим способом проверить — создать на C# метод с параметрами по умолчанию, а потом посмотреть в ildasm. Если будут перегруженные функции, значит дела все еще как и были, если будет запись в Reflection, значит все изменилось...