Полагаю, это отчасти связано с дизайном компилятора.Эрик Липперт написал в блоге о том, почему поля не могут использовать неявную типизацию, и я подозреваю, что некоторые из тех же аргументов применимы к методам.
Но вы могли бы легко получитьдвусмысленность в любом случае.Например:
var Method1(bool callMethod2)
{
return callMethod2 ? Method2() : null;
}
var Method2()
{
return Method1(false);
}
Каким должен быть тип?
Более простой пример:
var Method1(bool throwException)
{
if (!throwException)
{
return Method1(true);
}
throw new Exception("Bang!");
}
По общему признанию, такого рода двусмысленность может быть просто запрещена, но я подозреваю , что команда разработчиков чувствовала, что добавленная сложность обоих проектови реализация не стоила выгоды.Не забывайте, что они работают с ограниченными ресурсами - учитывая выбор между var
для методов и async/await
, я бы выбрал последнее в одно мгновение.(Конечно, есть и другие функции, которые я бы выбрал вместо dynamic
, но это другой вопрос ...)
Обратите внимание, что вывод типа возврата выполняется для лямбда-выражений, поэтомусама идея этого не сумасшедшая.Например:
IEnumerable<string> x = new[] { "x", "y", "z" };
var result = x.Select(s => { return s.Length; }); // Long form
Там компилятор выводит полный тип лямбда-выражения при выполнении разрешения перегрузки для Select
, преобразовывая его в Func<string, int>
.Не исключено применение к методам одних и тех же идей - просто сложно.