Да, я об этом и говорю: исключения должны использоваться для тех случаев, которые по сути не будут обрабатываться. Залогировали, возможно перезапустили вычисление. Все.

Другое дело, что я бы тоже не отказался от второго стандартного механизма обработки ошибок, где все было бы явно и с сахаром. Кажется, сейчас этим много кто интересуется.

В таком случае, я согласен и действительно не вижу проблемы в использовании исключений

интересно мнение Страуструпа на счет новых механизмов обработки ошибок: http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2019/p1947r0.pdf

Есть очень похожее предложение от Винцента Боте

Вообще с подобными монадическими интерфейсами в C++ следующая ситуация:
1) они в большинстве опираются на классы стандартной библиотеки, которые ещё не приняты
2) из-за 1) их пока не особо рассматривают, отодвигают в конец очереди

Так что бумагу пока не рассматривали

Думаю, что не только можно, но и нужно добавить сначала языковую возможность, как автор верно заметил, это очень похоже на корутины. И корутины тоже приняты без библиотечной поддержки. Я не считаю это катастрофой, в любом случае у пользователя должна оставаться возможность сделать собственную реализацию, независимо от наличия или отсутствия средств в стандартной библиотеке. А уж если у пользователя возможность появится рано или поздно — в чём проблема, если появится рано?

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

Есть трюк, позволяющий использовать корутины для монадического интерфейса

expected<float> get_float() noexcept
{
int _int = co_await get_int();
...
}

Так что можно уже сейчас экспериментировать )

expected<float> get_float() noexcept
{
int _int = co_await get_int();
...
}

Да, я знаю, более того, автор предложения ссылался на такую возможность и неплохо аргументировал, почему такая возможность ужасна)

Похоже выяснил где собака порылась... Оптимизации внезапно зависят от размеров объектника. Буквально добавляю несколько строк в одну функцию, в другой исчезают оптимизации char_traits::length для литералов. С jumbo builds вообще печаль получается :(

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

Очень точное определение

Именно по той же причине operator try() без библиотечной поддержки мог бы стать хорошим шагом, он, по сути, мог бы быть тем же самым ассемблером, разве что спектр применения значительно уже, чем у корутин

ЕСЛИ КТО-ТО СДЕСЬ СМОЖЕТ СКОМПИЛИТЬ И ЗАПУСТИТЬ headless_example — ВЫ MVP

https://chromium.googlesource.com/chromium/src/+/lkgr/headless/README.md

Minimal Valuable Product?

Тонко

Нет, я правда не понял.

MVP - most valuable professional

а не person? )

я компилировал и запускал.

(непонятно зачем потратил уйму времени)