Аргументы по умолчанию в C#

«При наличии общего механизма перегрузки функций аргументы по умолчанию становятся логически избыточными и в лучшем случае обеспечивают небольшое удобство нотации»
                                                                                            Б. Страуструп «Дизайн и эволюция С++»

Многие разработчики, перешедшие в .NET с языка С++ хотели увидеть в C# аргументы по умолчанию. И вот в C# 4.0 они появились, но с существенными ограничениями, особенно по сравнению с языком С++. Конечно эти особенности и ограничения не сложно запомнить, а их перечисление займет не больше пары строк, но вместо простого перечисления этих особенностей я предлагаю побывать в шкуре разработчиков этой фичи для языка платформы .NET и прийти к этим ограничениям и особенностям самостоятельно.

Варианты реализации

Смысл аргументов по умолчанию очень простой: класс, предоставляющий метод знает значение аргумента, подходящее многим его клиентам по умолчанию. Поэтому вместо перегрузки методов он использует один метод и делает один или несколько аргументов не обязательными:

class StreamWrapper
{
    public static void UseStream(Stream stream, bool needClose = true)
    { }
}

Прежде чем рассматривать реализацию аргументов по умолчанию в языке C# давайте рассмотрим варианты реализации этой возможности в принципе.

1. Использование перегрузки методов

Так, например, при наличии аргументов по умолчанию, компилятор мог бы создать два метода; аналогично тому, как мы поступаем в языках без аргументов по умолчанию:

// UseStream(Stream stream, bool needClose = true) преоразуется в 2 метода:
public static void UseStream(Stream stream, bool needClose)
{ }
public static void UseStream(Stream stream)
{
    UseStream(stream, true);
}

Это решение на первый взгляд может показаться разумным, но оно приведет к ряду проблем:

1. Как быть со стек-трейсом? Если при вызове второго метода произойдет исключение, то стек-трейс будет содержать детали реализации этой возможности. Можно заставить компилятор «инлайнить» второй вызов и просто продублировать код из оригинального метода, но это не всегда просто и возможно.

2. Как быть с языками, не знающими об аргументах по умолчанию? Для них среда разработки будет показывать два метода, что совсем не удобно!

3. Как быть с виртуальными методами и интерфейсами? Опять-таки, в языках, не знающих об аргументах по умолчанию появится возможность переопределить или реализовать лишь один метод.

Другими словами, чтобы реализовать аргументы по умолчанию таким способом потребуются изменения среды исполнения и других языков программирования. Поскольку аргументы по умолчанию – это скорее хотелка, то такие ограничения сделают эту возможность экономически не выгодной с точки зрения ее разработки (и я не знаю ни одного примера, где аргументы по умолчанию были бы реализованы таким образом).

2. Подстановка значений по умолчанию в вызывающем коде

Альтернативным решением, будет использование одного метода и в случае вызова метода без одного из параметров, компилятор подставит «втихаря» значения по умолчанию:

StreamWrapper.UseStream(stream);
// Эта строка заменяется компилятором в *месте вызова* на следующую:
// bool defVal = GetDefaultValueFromMetadata();
// StreamWrapper.UseStream(ms, defVal);

Именно таким образом реализованы аргументы по умолчанию в VB и С++, и именно так они и реализованы в C#. И хотя идея реализации этой возможности в языках С++ и C# похожи, разница тоже есть. Для подстановки значения по умолчанию в месте вызова компилятору нужно «добраться» до значения по умолчанию. И если для С++ это значит использование заголовочного файла, то в случае платформы .NET мы должны сохранить значение по умолчанию в метаданных сборки.

Реализация аргументов по умолчанию в C#

Итак, в языке C# используется подстановка значения по умолчанию в месте вызова метода. Как бы мы с вами реализовали эту возможность? Во-первых, при компиляции метода с аргументами по умолчанию, это значение мы бы сохранили в метаданных с помощью атрибутов (где же его еще хранить?).

В результате метод UseStream:

class StreamWrapper
{
    public static void UseStream(Stream stream, bool needClose = true)
    { }
}

Во время компиляции преобразовали бы его во что-то такое:

public static void UseStream(
    Stream stream,
    [Optional][DefaultParameterValue(value: true)]bool needClose)
{ }

После чего, изменили бы overload resolution таким образом, чтобы приведенный выше метод был доступен в случае вызова UseStream(ms). Затем в месте вызова осталось бы достать значение атрибута DefaultParameterValue и подставить его значение Value в качестве аргумента needClose.

ПРИМЕЧАНИЕ
Аргументы по умолчанию интегрированы в платформу .NET несколько сильнее, чем я описал. Так, в метаданных параметров метода отсутствует DefaultParameterValueAttribute, вместо этого, значение по умолчанию будет храниться непосредственно в экземпляре ParameterInfo.

Ограничения аргументов по умолчанию

Поскольку теперь мы знаем, что аргументы по умолчанию в C# реализованы на основе атрибутов и подстановки значения по умолчанию в месте вызова, то не сложно догадаться об ограничениях и особенностях этой возможности.

1. Ограничение значений по умолчанию

Поскольку значение по умолчанию хранится в атрибутах, то мы не можем использовать в качестве аргумента по умолчанию произвольные выражения:

void WithDateTime(DateTime dt = DateTime.Now) { }
// Будет компилироваться в случае: string s = ""
void WithStringEmpty(string s = String.Empty) { }
 
void WithMethodCall(int id = GetInvalidId()) { }
 
static int GetInvalidId() { return -1; }

Пользовательские атрибуты на данный момент могут хранить лишь константы времени компиляции, а значит аргументы по умолчанию также ограничены лишь константами. Можно было бы предложить компилятору «сериализовывать» выражения и сохранять его в атрибутах, но это решение потребовало бы на порядок больше усилий.

2. Проблема версионирования

«Встраивание» значение по умолчанию в место вызова происходит во время компиляции, а не во время исполнения. А значит мы получаем проблему версионирования, аналогичную той, что мы имеем с константами. При изменении значения по умолчанию метода, нам нужно перекомпилировать всех его клиентов, поскольку в противном случае, мы будем вызывать метод со старым значением по умолчанию.

3. Переопределение (overriding) значений по умолчанию

Поиск значения по умолчанию происходит во время компиляции, а это значит, что смешивать аргументы по умолчанию и полиморфизм нельзя. Давайте рассмотрим следующий код:

public class StreamWrapper
{
    public virtual void UseStream(Stream stream, bool needClose = true)
    {
        Console.WriteLine("NeedClose: {0}", needClose);
    }
}
 
public class AdvancedStreamWrapper : StreamWrapper
{
    public override void UseStream(Stream stream, bool needClose = false)
    {
        base.UseStream(stream, needClose);
    }
}
 

var ms = new MemoryStream();
var streamWrapper = new AdvancedStreamWrapper();
 
streamWrapper.UseStream(ms);
((StreamWrapper)streamWrapper).UseStream(ms);

В этом случае значение аргумента по умолчанию будет зависеть от «статического» типа переменной, через которую мы вызываем метод UseStream, поэтому в первом случае мы получим needClose равный False, а во втором случае – needClose равный True.

Это довольно известная проблема в языке С++, и особенности реализации аргументов по умолчанию привнесли ее и в C#. При этом, тот же РеШарпер сразу же предупреждает об “Redundant method override” (хотя я бы посоветовал сменить предупреждение на ошибку, поскольку речь идет не просто об избыточности, а об изменении поведения!).

3. Использование специального типа Optional<T>

На самом деле, существует еще как минимум один распространенный способ реализации аргументов по умолчанию. Вместо подстановки значения в месте вызова, мы могли бы получать значение в теле вызываемого метода, изменив тип аргумента с T на Optional<T>:

public void UseStream(Stream stream, Optional<bool> needClose)
{
    bool close = needClose.HasValue ? needClose.Value : true;
    // Или даже так
    bool close2 =
        needClose.HasValue ? needClose.Value : GetDefaultNeedClose();
}
 
private static bool GetDefaultNeedClose()
{
    return true;
}

Именно такой подход применяется в языке F#:

type CustomStreamWrapper() =
    
    let getNeedClose() = true
    
    // Необязательные аргументы можно использовать только в типах
    member public x.useStream (s: System.IO.Stream, ?needClose: bool) =
        let nc = defaultArg needClose (getNeedClose())
        // close stream if nc is true
        nc

Такой подход позволяет использовать выражения произвольной сложности для указания значения по умолчанию, хорошо работает с полиморфизмом (поскольку значение по умолчанию определяется во время исполнения, а не во время компиляции), но обладает своими недостатками.

Во-первых, значение по умолчанию становится неочевидным, поскольку его получение может быть в произвольном месте в коде метода.

Во-вторых, изменение простого аргумента на аргумент по умолчанию изменяет сигнатуру метода (ведь изменяется тип аргумента). В языках C++ и C# добавление значения по умолчанию аргументу не является «ломающим» изменением. В этом же случае, мы сломаем код, вызывающий метод через рефлексию, а также нам придется перекомпилировать всех клиентов этого метода. Это не страшно для промышленного кода, но может быть проблемным для библиотек.

UPDATE. Дополнительные ссылки

1. C# Bug: Using Reflection with Default Properties
2. Eric Lippert. Optional argument corner cases, part one
3. Eric Lippert. Optional argument corner cases, part two
4. Eric Lippert. Optional argument corner cases, part three
5. Eric Lippert. Optional argument corner cases, part four