Почему все перегрузки TryParse имеют параметр out?

Обновленный ответ:

В более поздних версиях C# вы можете объявить выходной параметр встроенным, что позволит вам удалить строку кода, которая вам не нужна в вашем примере:

string value = Console.ReadLine(); //Get a value from the user.

if (int.TryParse(value, out int num))
{
    Console.WriteLine("An integer");
}
else
{
    Console.WriteLine("Not an integer");
}

Вы можете просто проигнорировать результат в своем коде и больше не иметь этой лишней строки. У вас все еще есть лишний параметр, но так ли это?

Основное «почему» остается прежним и вряд ли когда-либо изменится. Метод должен был возвращать две вещи: bool, указывающий на успех, и int, указывающий результирующее значение в случае успеха. (Я не могу придумать другого способа передать результат, а вы?) Поскольку метод может возвращать только одну вещь, а пользовательский тип результата кажется излишним для этого, было принято решение вернуть bool и получить результат быть параметром out. И как только это решение было принято, оно должно оставаться в силе на протяжении всего языка.

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

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

Исходный ответ:

Короткий ответ: «Потому что так определен метод». Возможно, случайно кто-нибудь из языковой группы C# найдет этот вопрос и объяснит, почему были приняты решения, но на данный момент это мало что меняет. C# — это статически компилируемый язык, и сигнатуры методов должны совпадать, так что это именно так.

(Представьте, если бы они изменили это и сломали .TryParse() во всех существующих кодовых базах. Это было бы... плохо.)

Однако вы можете обойти это в своем собственном коде. Что-то столь же простое, как метод расширения, может помочь вам:

public static bool IsInt(this string s)
{
    int x = 0;
    return int.TryParse(s, out x);
}

Затем в вашем коде вам просто нужно вызвать этот метод из строкового значения:

string value = Console.ReadLine();
if (value.IsInt())
    Console.WriteLine("An integer");
else
    Console.WriteLine("Not an integer");

TryParse — относительно сложная операция для определения int представления string. Если бы была перегрузка, которая просто возвращает bool, очень вероятно, что многие (неопытные) разработчики будут следовать этому неэффективному шаблону:

int myInt = -1;
if(int.TryParse("123"))
    myInt = int.Parse("123");

У него есть параметр out, потому что в подавляющем большинстве случаев, когда люди его используют, им нужен int (или двойной, или десятичный, или datetime, или что-то еще), который был проанализирован.

Если вам не нужно/не нужно анализируемое значение, и вы делаете это все время, вы можете написать свою собственную «оболочку» для .TryParse(), которая просто берет строку.

В этом примере (и вы могли бы сделать его более общим, я уверен) вы могли бы сделать что-то вроде

public static bool TryParseNoOutput(this string value)
{
  int noNeed = 0;
  return int.TryParse(value, out noNeed);
}

Затем в вашем коде (в данном случае) вы бы назвали:

string value = Console.ReadLine();
if(value.TryParseNoOutput()) Console.WriteLine("An Integer");
else Console.WriteLine("Not an integer."):

Редактировать: Как было указано в комментариях, я пытался вызвать "int.TryParseNoOutput", когда я определил его как расширение строки. Ответ был обновлен, чтобы отразить это.

Почему в TryParse есть выходной параметр?
По очень простой причине реализации TryParse.
Способ, которым вы определяете, можно ли что-то анализировать, заключается в анализе этого! Если вы можете что-то разобрать, то это можно разобрать. Если вы не можете разобрать его, то он не поддается разбору.

Таким образом, определяя, парсится что-то или нет, если это можно парсить, значит, мы это уже разобрали! Было бы глупо отбрасывать это проанализированное значение (любой, кто задается вопросом, можно ли что-то разобрать, скорее всего, заинтересован в проанализированном результате), поэтому проанализированное значение возвращается.

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