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

VE>Тогда if-else тоже динамическая типизация.

Если при этом проверяется внутреннее устройство данных, то бишь их тип — несомненно.


VE>>>Не понял. Что должна делать такая функция? Ругаться при компиляции на разные типы? Или молча жрать все? Тогда в чём замысел?

V>>Например том, чтобы она смогла быть применена в таком контексте, где a и b могут выводиться как одни и те же типы, а могут и нет.

VE>Зачем?
VE>Тем более, что это не ПП, а речь-таки о нём шла.

V>>Речь идет о возможностях техники навроде static_if в С++. Возможностей Хаскеля для сравнимой реализации такой техники недостаточно, т.к. нет аппарата compile-time вычислений.
VE>Во-первых, как это нету?

Так что нету. Потому что нет параметризации типов константами и нет compile-time диспетчеризации по этим константам и нет частичного или явного инстанциирования шаблонных типов для конкретных комбинаций аргументов. Есть только такое инстанциирование для ф-ий.


VE>Во-вторых, можно пример, когда static_if не является сам по себе костылём?

Ха. Тогда любая статическая система типов — это костыль сам по себе, т.к. это способ перенести ограничения прикладной логики на компилятор. Я могу спросить в ответ привести пример, когда классы типов Хаскеля не являются костылем? Вот это аналогично. static_if покрывают возможности ограничений, вводимых классами типов, + еще позволяют сверху наложить кучу других ограничений. На сегодня, используя boost::type_traits — выразить как ограничения фактически любые отношения м/у типами или мемберами типов в системе типов С++.