Замыкания на переменных цикла в C# 5

Очень странное нововведение, а вдруг в существующем коде где-то использовалось замыкание на current в благих целях?

Несколько сотен постов на stackoverflow говорят о том, что очень-но многие разработчики считают именно «1 2 3» естественным результатом.

Естественно, после того, как вы узнали как это дело *устроено*, то все вопросы отпадают. Но ведь помимо нас с вами, есть еще пара миллионов индусов (это я про мировозрение, а не рассовую принадлежность), которые с нами не согласятся, поскольку они не знают да и не хотят знать, как это дело внутри устроено.

Поскольку большинство разработчиков не представляют себе как работает .net внутри, то утверждение про разумность имеет смысл.

На мой взгляд «неправильный» код выглядит куда более естественно, чем код со временной переменной. Можно понимать что он неправильный, и чувствовать, что всё равно хотелось бы писать так. Тут Липперт молодец.
Вообще в C# еще несколько таких мест.

На самом деле не сломает. В цикле foreach всегда объявляется новая переменная. А поскольку раньше на неё никто не делал замыканий, то новая реализация ничего не сломает.

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

Поведение будет таким же «согласованным» как и ранее, но для этого нужно понимать две вещи: (1) экземпляр класса замыкания для каждой области видимости и (2) каждая итерация цикла foreach содержит новую переменную i.

В данном случае это означает, что для переменной jj будет создан один объект замыкания, который будет шарится всеми остальными объектами замыкания для каждой итерации.

Т.е. этот код можно рассматривать таким образом:

var actions = new List<Action>();
var jjClosure = new jjClosure();
jjClosure.jj = 0;

foreach(var i in Enumerable.Range(1, 3))
{
  // внутренний объект замыкания содержит ссылку на внешний объект замыкания
   var iClosure = new iClosure() {i = i, jjClosure = jjClosure};

   // () => Console.WriteLine(i, jj) теперь перехало в метод Action замыкания iClosure.
  // Тело iClosure.Action выглядит так:
  // Console.WriteLine(this.i, this.jjClosure.jj);
   actions.Add(iClosure.Action);
}

В результате чего мы и получим 1 3, 2 3, 3 3, поскольку всеми iClosure будет использоваться один и тот же объект jjClosure.

Это фича именно компилятора языка C# 5.0, причем не важно, на какую платформу мы таргетимся, т.е. при запуске этого кода из VS11 будет результат «1 2 3», даже если мы таргетимся на .NET Framework 3.5.

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

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

Ответьте мне, пожалуйста, каким образом конструкция i++ может быть применима к переменной, генерируемой для каждой итерации заново?

Побочный эффект на пересечении двух концепций.

Читайте статью внимательнее.

а зачем это делать?
в общем случае код просто не скомпилируется.

На самом деле, у Рихтера об этом все написано, включая магию генерации классов замыканий при захвате внешних переменных из анонимного метода. Просто страшных терминов, типа closure у него нет.

См. главу 17. Delegates раздел Syntactical Shortcut #3: No Need to Wrap Local Variables in a Class Manually to Pass Them to a Callback Method