Неявно типизированные поля в C#

> В статье как-то совсем не освещено, например, отличие var от dynamic.

Некоторые принципы проектирования, такие как Single Responsibility Principle применяются не только при создании программ, но и, например, при написании статей. У нормальной статьи есть определенная цель, которую преследует автор при ее написании. Цель этой статьи отражена в названии и нескольких первых абзацах.

И в целях автора просто не было целей сравнивать var и dynamic по нескольким причинам. Во-первых, это откровенный баян; в любой вводной статье про неявно типизированные переменные будет сказано «не путайте var с динамической типизацией». Во-вторых, у статьи есть определенное «предусловие»; предполагается, что автор знает, что такое неявно типизированные переменные и хочет узнать/понять, почему не бывает неявно типизированных полей; в-третьих, банально, var появился раньше, чем dynamic; из этого довольно легко сделать вывод, что это не одно и тоже.

А вот ваше последнее предположение совсем интересное. У полей нет никаких методов установки и получения значений. Вы путаете поля со свойствами. Так что последние несколько ваших фраз таки и остались для меня загадкой.

Да ну, я же не всерьез спрашивал :)

Конечно же я знаю в чем отличия. А зачем в статье писать про отличия var от dynamic? Разные вещи для разных задач, зачем их сравнивать.

«var flag = defaultFlagValue»
Вот за это как раз и надо бить.

Во-первых, flag бывает только bool, тут не надо лезть и смотреть (а программиста, который вписал туда string — бить). Во-вторых, названий типа flag надо избегать (привет МакКоннелу), потому что совершенно не понятно, что этот flag отмечает.

И вары тут совершенно не при чем.

Эстетически пример красивее, но по логике — более опасен.

В случае с объявление типа внутри перечисления происходит сразу две вещи.
Одна обязательная — объявление типа элемента.
Вторая необязательная — объявление даункаста.
Поскольку даункаст операция не безопасная, то мне хотелось бы её контролировать отдельно.

В случае с объявление типа мы можем сделать и апкаст, например
foreach(object i in new List<int>{ 1, 2, 3,})
но после введение ко- и контравариантности в дженерики я даже не знаю где такое преобразование может понадобиться.

Я этого не говорил. Но более очевидной записью будет каст коллекции.

> «Изменяемые состояния»
Моя русский плохо плохо. =)
Я имел ввиду, что item в foreach это переменная. В то время как в лямбде скорее всего параметр меняться не будет.

Ну а ворнинг решарпера как раз предупреждает о подобной проблеме:
var list = new List<Action>();
foreach (var i in Enumerable.Range(1, 5))
{
    list.Add(() => Console.WriteLine(i));
}
list.ForEach(x => x());

> Более функционально, это функциональный стиль.
Более функциональный стиль в данном случае лишь следствие. Я определил как должен вести себя поток управления. Декларативно описал. Не описывая прямого поведения кода.
Это декларативный стиль.

Функциональный стиль — это когда функции являются первоклассными значениями и используются функции высших порядков. В данном случае цепочкой вызовов Linq методов декларативно описивает поток исполнения, пускай и используя ФВП.
Так что функциональный стиль тут вторичен.

Это тоже функциональненько, но без декларативности
foreach(var a in collection.Cast<A>())
{
    Func<A,B> builder = Generate(genericBuilder, () => a);
    foreach(var b in builder(a))
    { //bla bla bla
    }
}