Интересный вопрос.
Во-первых, рассмотрим разницу между анонимными методами и лямбдами. С точки зрения разработчика компилятора, наиболее важным отличием является то, что лямбда-выражения могут требовать от компилятора определения типа параметров из целевого объекта, которому назначается лямбда-выражение; Анонимные методы C # 2 не имеют этой функции. Эта функция кажется небольшой разницей, но на самом деле она имеет серьезные последствия для реализации компилятора. Прочтите мою серию блогов по этой теме, чтобы узнать, почему это так:
http://blogs.msdn.com/ericlippert/archive/2007/01/10/lambda-expressions-vs-anonymous-methods-part-one.aspx
Итак, теперь давайте перейдем к вашему актуальному вопросу: почему мы не можем сделать вывод о внешнем / референциальном состоянии из целевого типа по параметрам лямбда. То есть, если у нас есть делегат void D (out int x), то, безусловно, D d = x => {x = 10; } может сделать вывод, что x "out int".
Нет никаких технических причин, по которым я не знаю, почему мы не могли этого сделать. Внутри компилятора типы out / ref представлены как типы, как и любые другие.
Однако функции не выполняются только потому, что они могут быть реализованы; они выполняются, потому что для этого есть веские причины. Для лямбда-выражений убедительной причиной для вывода типов в первую очередь является LINQ; мы хотим иметь возможность выполнять простое синтаксическое преобразование понимания запроса в вызов метода с лямбда-выражениями, и позволить механизму вывода типа метода определять типы всех лямбда-параметров. Ни один из сгенерированных методов LINQ не имеет делегатов с параметрами out или ref.
Итак, у нас нет веских причин использовать эту функцию. Делегаты с параметрами out / ref встречаются относительно редко. И назначение лямбд этим делегатам еще реже. Так что это функция, которая нам не нужна, и она никому не приносит пользы.
C # 3 был «длинным полюсом» в расписании Visual Studio; у нас было запланировано наибольшее количество рабочих дней среди всех команд, которые поставляют компонент в VS. Это означало, что каждый день мы отклонялись от графика, все подразделение отставало. Это было сильным препятствием к тому, чтобы тратить время на ненужные функции, которые никому не приносили пользы. Так что работа так и не была сделана.
Я согласен с тем, что было бы неплохо быть здесь более последовательным, но вряд ли это произойдет. У нас много высших приоритетов.
person
Eric Lippert
schedule
02.01.2010
delegate
правило состоит в том, что вы либо ничего не указываете (оставляете даже круглые скобки()
), либо указываете полную сигнатуру, включая типы параметров и модификаторы, такие как _3 _ / _ 4_. Так что _5 _ / _ 6_ не исключение. Что касается лямбда-выражений, ваша идея имеет смысл, но я не уверен, что считаю ее хорошей. Синтаксис(out t) => { ... }
делает вид, что это тип параметра. Тогдаt => { ... }
лучше, но это может быть опасно, если кто-то забудет значениеD
и отредактирует тело{ ... }
лямбды, не осознаваяout
природуt
. - person Jeppe Stig Nielsen   schedule 22.06.2013