Здравствуйте, Evgeny.Panasyuk, Вы писали:

EP>Это в том числе тоже является недостатком.

Этот "недостаток" есть везде, где есть value типы.

НС>>А это для лучшего перформанса.
EP>Так я и говорю, этот код пришлось написать из вполне конкретных практических соображений.

Практические соображения и алгоритмическая выразительность это разные вещи. Алгоритмически все это можно было бы уложить в один небольшой метод.

EP> Был бы язык/платформа/компилятор мощнее — его бы и не пришлось писать, о чем собственно и речь.

Мощность штука не скалярная. Везде есть трейд-офф. Мощность текстовых шаблонов, к примеру, компенсируется отсутствием этих шаблонов в рантайме.

НС>>Но аналогичная ситуация с чудовищной кашей в твоей шаблонной магии тебя почему то устраивает, а тут прям какая то вселенская проблема и ужас ужас.
EP>Вот что-что, а передёргивать у вас всех здорово получается
EP>Шаблонная магия нужна для реализации EDSL запросов времени компиляции

Далеко не только. Еще недавно она была нужна даже для таких базовых вещей как лямбды. И для плохонького аналога анонимных типов она понадобилась. Причем ее не хватило в итоге, и пришлось допиливать при помощи макросов препроцессора.

EP>Для обсуждаемого простейшего алгоритма поиска минимального/максимального элемента никакой магии не нужно.

Ты обсуждаешь простейший алгоритм на С++ с его конкретной реализацией для дотнета, содержащей кучу подробностей, связанных со спецификой платформы. Это самая натуральная демагогия. Интересно сравнение алгоритмической выразительности — так возьми тогда чистый алгоритм, в чем проблема? Или давай вспомним, что куча плюсовых OR/M вообще не поддерживают NULL в value колонках, видать из-за крутой алгоритмической выразительности.