Все равно потом свичем разбирать

В коде LLVM применяют такой подход, про которых говорит Александр, может быть будет полезно, вот описание их класса https://llvm.org/doxygen/classllvm_1_1Expected.html а вот - самого подхода For functions that can fail but need to return a value the Expected<T> utility can be used. Values of this type can be constructed with either a T, or an Error. Expected<T> values are also implicitly convertible to boolean, but with the opposite convention to Error: true for success, false for error. If success, the T value can be accessed via the dereference operator. If failure, the Error value can be extracted using the takeError() method. https://llvm.org/docs/ProgrammersManual.html#recoverable-errors

Зависит от того нужны ли детали

Я так понял это что-то вроде std::expected предлагается

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

В моем случае std::error_code это прямо буквально то, что нужно. Вопрос не в том, какой подход использовать, а собственно в производительности данного подхода, в частности при возврате из функции. Где-то читал, что там все не так же просто, как например при возврате инта. Потому и спрашиваю.

Думал, может кто сталкивался

Да похоже на правду - стандартная реализация Try/Either

В таком случае лучшим решением написать функцию и померять производительность

Ну это вернуть или результат или ошибку

Было бы здорово попробовать, если бы std::expected прошел в двадцатый. Но не в данном кейсе

И тот факт, что упрется именно в возврат значения, а не время работы самой функции

А не "прикрутить кастомные коды"

Забей и используй то что удобнее

Но скорость жи...

А что с ней?

Если медленно - не покатит

Вот  будет медленно - тогда и приходите

Поздно будет переделывать, это в интерфейсе библиотечки)

Но да, придется тестить, раз никто не знает