Observable.Generate и перечисление списков

В библиотеке реактивных расширений (a.k.a. Rx Reactive Extensions) существует вспомогательный метод Observable.Generate, который позволяет генерировать простые observable-последовательности.IObservable<,string>, xs = Observable.Generate<,int, string>,(
initialState: 0, // начальное значение
condition: x =>, x <, 10, // условие завершения генерации
iterate: x =>, x + 1, // изменение значения
resultSelector: x =>, x.ToString() // преобразование текущего значения в результат
), xs.Subscribe(x =>, Console.WriteLine('x: {0}', x)),

ПРИМЕЧАНИЕ
Обратите внимание на явное указание параметров обобщенного метода. Причина такого странного поведения (ведь обобщенные параметры методов должны спокойно выводиться компилятором) в том, что в компиляторе языка C# есть известный баг, в результате которого, вывод типов плохо дружит с именованными параметрами. Подробнее об этом можно почитать на stackoverflow или на connect-e. Да, кстати, это дело пофиксили в Visual Studio 11.

Метод Generate напоминает простой цикл for, который состоит из тех же самых этапов: инициализации начального значения, условия выхода из цикла и изменения переменной цикла. И если мы захотим сгенерировать обычную последовательность в памяти, то мы будем использовать именно цикл for внутри блока итераторов:static IEnumerable<,string>, GenerateSequence() {
for (
int x = 0, //initialState
x <, 10, // condition
x = x + 1 // iterate
)
{
yield return x.ToString(), // resultSelector
} } static void Main(string[] args) {
var xs = GenerateSequence(),
foreach (var x in xs)
Console.WriteLine('x: {0}', x), }

Оба варианта кода эквивалентны, но если в первом случае создается push-последовательность (в виде интерфейса IObservable of T), которая будет самостоятельно уведомлять о поступлении новых элементов, то во втором случае мы получаем pull-последовательность (в виде интерфейса IEnumerable of T), из которой нужно плоскогубцами эти элементы вытаскивать.

ПРИМЕЧАНИЕ
Если очень коротко, то pull-модель это такая модель взаимодействия приложения с окружающим миром, когда ведущую роль выполняет именно приложение. Если посмотреть на интерфейс IEnumerable, то именно вызывающий код управляет потоком элементом, вызывая метод MoveNext для перехода к следующему. В push-модели действия разворачиваются по-другому: внешнее окружение само уведомляет приложение о некоторых событиях (например, о наличии новых данных), а приложение лишь реагирует на них. Подробнее об этих моделях, о дуализме интерфейсов IEnumerable/IObservable, а также о других возможностях библиотеки реактивных расширений можно почитать в статье:
Реактивные расширения и асинхронные операции.

Поскольку интерфейсы push и pull-последовательностей (IObservable of T и IEnumerable of T, соответственно) являются такими похожими, то к нам в голову легко может затесаться мысль о преобразовании из одной формы последовательности в другую:int[] ai = new[] { 1, 2, 3 }, IObservable<,int>, oi = Observable.Generate(
/*initialState:*/ ai.GetEnumerator(),
/*condition:*/ e =>, e.MoveNext(),
/*iterate:*/ e =>, e,
/*resultSelector:*/ e =>, (int)e.Current
), oi.Subscribe(i =>, Console.WriteLine('i: {0}', i)),

В целом ничего криминального, и при выполнении этого кода мы ожидаемо получим:

1
2
3

Но что, если вместо массива нам захочется сделать тоже самое со списком:List<,int>, li = new List<,int>, {1, 2, 3},
IObservable<,int>, oi = Observable.Generate(
/*initialState:*/ li.GetEnumerator(),
/*condition:*/ e =>, e.MoveNext(),
/*iterate:*/ e =>, e,
/*resultSelector:*/ e =>, e.Current
), oi.Subscribe(i =>, Console.WriteLine('i: {0}', i)),

И, совершенно естественно, что в этом случае мы получим бесконечную последовательность нулей.

ПРИМЕЧАНИЕ
Да, я знаю, что самым простым способом преобразования простой последовательности в observable-последовательность, является использование метода расширения Observable.ToObservable, который расширяет интерфейс IEnumerable. Но, предположим, что мы либо о нем не знаем, либо нам нужна более сложная логика, доступная в методе Generate.

Причина такого поведения кроется в том, что енумератор класса List of T (а также большинства других коллекций BCL) является структурой, а не классом. А, как нам известно, изменяемые структуры (ведь енумератор изменяет свое внутреннее состояние) не очень вяжется с передачей по значению. В результате этого мы постоянно пробуем изменить копию енумератора, а не исходный енумертор, переданный нами в методе Generate.

Изменяемые структуры это зло, и только стремление к оптимизации кода для наиболее распространенного сценария использования енумераторов привели к тому, что разработчики BCL сделали их структурами, а не классами. Поскольку наиболее частым сценарием использования енумерторов в C# 2.0 было использование его в цикле foreach, который никак не страдал от проблем с изменяемыми структурами, то было принято решение сэкономить несколько тактов процессора и использовать для енумератора именно структуру, а не класс.

ПРИМЕЧАНИЕ
Подробности о том, почему это было сделано именно так, можно почитать
в одном из постов Sasha Goldshtein, а также в ответе Эрика Липперта на stackoverflow. О других же проблемах изменяемых значимых типов можно почитать в статье: О вреде изменяемых значимых типов.

Решается эта проблема довольно просто: для этого достаточно привести исходное значение енумератора к интерфейсу, что приведет к его упаковке и последующей модификации общей переменной, расположенной в управляемой куче, а не к изменению копии:List<,int>, li = new List<,int>, {1, 2, 3},
IObservable<,int>, oi = Observable.Generate(
/*initialState:*/ (IEnumerator<,int>,)li.GetEnumerator(),
/*condition:*/ e =>, e.MoveNext(),
/*iterate:*/ e =>, e,
/*resultSelector:*/ e =>, e.Current
), oi.Subscribe(i =>, Console.WriteLine('i: {0}', i)),