Комментарии 17
Для того что бы это работало надо ставить заплатку на .NET 4.0 и к студии(либо переходить на VS2012).
Да, это может быть большой проблемой для команды.
Всей команде придется патчить VS2010 либо переходить на VS2012. На всех конечных компьютерах надо быть уверенным не только в .NET 4.0 но в KB2468871. На всех билд/тест машинах должна стоять заплатка. В зависимостях к проекту надо не забыть о Microsoft.Bcl.Async.

О варианте с заплаткой и компиляцией из C# 5.0 под .NET 4.0 я уже писал в начале статьи.
«тимлид грозит небесной карой за смену платформы»

и правильно сделает! Следующий программист, кто будет работать с Вашим кодом, скажет: WTF!

И да: KISS! KISS, BABY!
Не очень ново. После выхода .Net 2.0 много подобного появлялось.

Плюсы: красиво для того, кто понимает и автора. Минусы: некрасиво для остальных.

Когда «остальные» погружаются в код с yield и разбираются настолько, что «понимают», то они вступают в секту приравниваются к автору, заодно дописывая пару красивостей к библиотеке и коду.
А потом приходит тимлид/пм…
Да, не спорю, баян. Но, он делает код с множеством вложенных «продолжений» или колбеков проще для восприятия.

Могу еще написать статью про нелегкое дело приведение/конвертации типов в .NET. Только в mscorlib и System.dll около 4х разных способов привести/сконвертировать один тип в другой. В бонус будет страшный классец(весь в генериках), который скрывает детали за одним интерфейсом: TypeConvert[Uri].From(«schema://localhost/»).
Для меня yield — отложенное формирование IEnumerable

Напишите, пожалуйста, «остальным» круг задач для которых нужно использовать yield кроме формирования IEnumerable в production коде.

Ну если не IEnumerable, то это магия какая-то…
Если ведется разработка desktop-приложения (Microsoft .NET Framework 4.0, Microsoft Visual Studio 2012), то для решения описанной задачи, можно использовать альтернативное решение от компании Microsoft в виде дополнительной библиотеки: описание проекта, пакет NuGet. Минус: дополнительная библиотека (~65KB). Плюс: код использования async/await полностью повторяет таковой для Microsoft .NET Framework 4.5, при переходе на новую версию просто убирается ссылка на библиотеку.
Штука достаточно мощная. Например, в новом питоне предлагается на таких «корутинах» написать целый стэк для написания вёб-серверов (и не только их). К сожалению, в C#5.0, как это видно, yield return сильно ограничен тем, что а) ничего не возвращает извне и б) не дружит с try {..} catch {..}.
У питоновцев уже есть технология continuation (stack-less Python) которая дает больше контроля над потоком исполнения и меньше проблем с продумыванием точек выхода/возврата через yield. А по поводу недостатков дотнетовского yield, то а) можно прокинуть «канал» с входящей информацией через аргументы б) try/catch работает, но с ограничениями на возможность yield внутри блока. и да, это не побороть
Странный какой-то тимлид, если запрещает или не планирует переход на .NET 4.5.

Я сам тимлид, задача по переводу проекта на .NET 4.5 шла именно от меня.
Перевод прошел быстро и без серьезных проблем.

Потом запустили рефакторинг существующего кода по работе с асинхронностью, а так же перевод методов сервисов только на async.
Вы даже не представляете на сколько чище и понятнее стал код с переходом на async/await (особенно кода ушли IAsynResult, события т.д и).
Поэтому я люблю С++ и сопутствующий ему Qt, в котором так хорошо пропагандированны сигнал-слоты (async вызовы — альтернатива колбекам)
Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.