Он не для игровых движков, но 2д игру на идрисе я видел

Я в качестве аргумента я просто приведу вот эту бумагу, её определённо писал кто-то более компетентный в вопросе, чем я и там на 12 странице в табличке можно увидеть, где автор считает этот пункт нарушенным и сравнивает в том числе с кодами возврата и expected<T,E>/outcome<T>

А мне надо, чтобы железо плакало кровавыми слезами, атмеги в том числе.

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

Но интерпретировать монады в трайкетчи во многих случаях возможно

но ведь тип вокруг std::expected не нуждается в try-catch?

Интерпретируй в них

зачем, если у меня уже есть expected?

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

Потому что громоздко и невыразительно

с методами .then/.else громоздко и невыразительно?

Да

Такое на джавке было ещё с 8 версии

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

get_opt().or_else([]{std::cout << "get_opt failed";});
get_opt().or_else([]{throw std::runtime_error("get_opt_failed")});

Я особо не против, но как я уже писал выше, не вижу прям сильного преимущества перед обычными исключениями. Допилить бы noexcept, и большинство остального станет не нужно

Исключения определённо более эффективны в коде в котором success path происходит чаще, чем failure path. Потому что коды возврата ты должен проверять в любом случае на всём стеке вызовов, а исключения на success path ничего не стоят

>success path происходит чаще, чем failure path

Это думаю бОльшая часть кода

ой не факт

у меня было дело с овносквернисом который 500-ил мне 60% запросов