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

EP>>От Optional отличие только в том, что внутри могут хранится разные исключения, а не только bad_optional_access.
__>в boost::optional<T> тоже зашит эксепшн?

Если он пустой, и безусловно доставать из него значение — да, будет исключение.

__>мне нравится сама идея — возможность самому расширять любой тип значением undefined, чтобы замкнуть хотя бы какие-то операции

Мне не нравится инфицирование всех выражений undefined'ом.

__>>>мм... может, я неправильно выразился. я имел ввиду подход, когда вместо того, чтобы считать a/0 неопределенностью, просто расширяют тип вещественных чисел за счет введения значения NaN, для которого полагается
__>>> a @ NaN -> NaN
__>>> NaN @ NaN -> NaN
__>>>(здесь @ — любая операция)
EP>>Это аппликативный функтор, а не монада.
__>а я думал, это что-то из разряда хаскелловской монады Maybe

Каждая монада это аппликативный функтор, но не наоборот. Если использовать именно монадические свойства Maybe, например через Haskell'евский do-синтаксис, то на первом Nothing'е весь поток управления остановится, собственно для этого и происходит заворачивание в do-синтаксис, чтобы был контроль над потоком управления (что особенно видно если вручную расписать замыкания и bind'ы).

Если же речь идёт про лифтование произвольных операций как в твоей табличке выше, то для этого достаточно аппликативного функтора.

__>>>в этом случае даже если у вас произойдет деление на нуль, поток управления все равно продолжит течь, как ни в чем не бывало, предоставляя вам свободу выбора, где делать проверку на валидность соответствующего значения.
EP>>Монада в этом контексте как раз и отличается от аппликативного функтора тем что может прервать поток управления, так как весь этот поток управления протекает через неё.
__>ну, я не спец. но интуиция мне подсказывает, что монады в чистом функциональном языке программирования вводились не для того, чтобы туда протаскивать такие императивные вещи, как исключения. возможно, я ошибаюсь.

Их изначально именно и протаскивали ради императивных вещей, в частности таких как ввод-вывод.
Собственно исключения в Haskell именно как монада и реализованы.

__>>>в случае же с эксепшенами обычный поток управления с необходимостью будет прерываться. а значит, программисту придется "всовывать" в обычную логику еще и логику перехватов и обработок исключений.

EP>>Вообще-то наоборот — с исключениями мы имеем обычную логику не замусоренную проверками и обработками. Обработка же обычно происходит где-то наверху стэка.

__>ну как же не замусоренную, если вам придется продумывать "а что будет, если вот именно в этом месте поток исполнения прервется и пойдет по совсем другому пути" и вставлять предусматривающий такой ход код?

Если речь идёт про Exception safety, то на C++ обычно всё что требуется для basic guarantee было бы и без исключений. Если же речь про strong guarantee, которую часто ассоциируют с транзакционностью — то её придётся "продумывать" в любом языке

__>кроме того, одна и та же нештатная ситуация может быть критической в одном случае и некритической в другом. и если она может возникнуть, например, в функции f() которую вы используете в нескольких местах, то вам придется во всех местах использования ставить трай-кэтчи, замусоривая код,

Почему же во всех местах использования? Только в тех, где это критично.

__>тогда как в случае с аналогом NaN такой необходимости не будет.

Если в каком-то месте критично чтобы вызов f() прошёл нормально, вернув нормальный результат, то и в случае с NaN'ами придётся городить проверки

__>другими словами, ексепшены принуждают программиста под угрозой повалить программу ловить их всюду,

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

__>тогда как "NaN-подход" просто дает возможность узнать валидность вычисления там, где эта валидность действительно принципиальна для программиста.

Почему эта мифическая угроза заставляет ловить везде исключения, но при этом не заставляет проверять NaN-ы?