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

Pzz>Есть задачи прочитать значение из файла, ввести его от пользователя, получить по сети и т.п., и осмысленная обработка ошибок занимает больше кода, чем собственно получение значения.

Вы умалчиваете о том, что задача "прочитать значение из файла, ввести его от пользователя, получить по сети и т.п." не определяет детали реализации. А в этих деталях будет скрываться то, сколько ошибок вы допустите вручную проверяя все и вся. Как раз возможность реализации типов, подобных constrained_value, вносит дополнительную степень защиты и явно определенные контракты. Вы из кода будете видеть, что отсюда читается значение в таких-то единицах, затем преобразуется в такое-то значение из такого-то диапазона и приходит к передаче в сеть строго вот таком-то виде.

Вы все это сможете увидеть в типах и компилятор с run-time будет бить вам по рукам за каждый шаг в сторону. Это сильно лучше, чем обычные int-ы или float-ы с комментариями вокруг них.

Pzz>Говорить об инструменте имеет смысл в контексте решения практических, а не школьных, задач.

Так вы же не можете в примеры. Ну вот совсем. Ваш максимум -- это сравнение с презервативами. Ничего предметного в обсуждении от вас не было. Ну, кроме демонстрации незнания C++.

Pzz>Если довести ваш пример до нормального состояния, что там был ваш constrained_value, что его не было, разница будет не шибко заметна.

Давайте сначала увидим ваш вариант этого constrained_value на чистом C. После чего можно будет, если будет возможность, поговорить и о том, чего вы в наличии и использовании constrained_value в упор не понимаете.

Pzz>Я, вообще-то, не хочу иметь в программе переменную, которая выглядит как целочисленная,

Так она и не выглядит как целочисленная. Она выглядит как жесткий контейнер для одного значения.

Pzz>Говорю, да. В программе на C++, скорее всего, ничего, кроме проверки, встроенной в constrained_value, и не будет. И исключение никто не будет обрабатывать до самого верха. А наверху приделают кнопочку "ой, программа упала, послать дамп разработчикам?". Таков он, человеческий фактор.

Давайте назовем вещи своими именами: в вашей программе на C++, скорее всего, ничего, кроме проверки, встроенной в constrained_value, и не будет. И исключение вы не будете обрабатывать до самого верха.

Так оно всяко объективнее получится.

Pzz>Угу. А потом мы начинаем сводить в одном проекте 5 библиотек, каждая из которых содержит свою реализацию expected, совершенно идентичную 4-м остальным, но формально несовместимую с ними, потому что разные типы.

Вообще-то не зря была дана ссылка на expected, поскольку это уже доступная сейчас реализация того, что будет в C++20.

Но даже такой зоопарк будет сильно лучше, чем обычный int в чистом C, который будет гулять между модулями вообще без какой-либо сопроводительной информации.