Товарищи, подскажите. Решил воспользоваться советом из этого чата, заменить исключение из

конструктора, на фабричную функцию.

Набросок кода:
class A {
A(int a) noexcept;
public:
static tl::expected<A, std::error_code> Create(some args) noexcept {
// some code produced value "a";
return a;
};

И вот так не компилируется.
Если сделать конструктор публичным, то ок.
Проблема в том, что когда expected хочет сконструировать А от а, то std::is_constuctible для A возвращает false.
Как победить?

friend struct expected

френд на expected тоже не помог

перенести конструктор внутрь просто напросто

может return A(a)

да. проблема была в том, что я подумал, что move-ctor/move-assigтment можно сделать default (что конечно не так). https://godbolt.org/z/WcE3dqTqE если нормально реализовать, то как говорил @Kelbon, компилятор всё правильно увидел и убрал деструктор временного объекта (но это только с оптимизацией) Так что, то что предложили через тэг, "помогло" сделать и дебаг "оптимальным"

Может как-то переделать чтобы не было такой сигнатуры изначально? Сами по себе конструкторы бросающие исключения это не круто, а с expected мы получаем ту же проблему в другом агрегатном состоянии. Сделать метод std::optional<std::error_code> Create()

Работал однажды с кодом который в конструкторе делал два http-запроса, вот там была ржомба при рефакторинге сетевых походов

конструктор бросающий исключение - это наоборот фишка! Ведь если класс, есть врапер над ресурсом, а получить ресурс не получилось, то как ещё зафейлить создание объекта? А чем optional лучше, Наоборот "приход" expected в плюсы - это огонь! Какую проблему мы получаем с ним?

Да по моему опыту если конструктор умеет бросать исключения, то значит там внутри какая-то логика в десятки-сотни строк кода и это уже антихайп, потому что в идеале в конструктор не надо совать сложную логику, потому что исключение в конструкторе это как-то противно. "Врапперам над ресурсами" можно определить bool operator(), который вернет false при ошибках, так будет более C++-way имхо (и соответственно const std::error_code& get_error() const). Какие врапперы из STL бросают исключение если получить ресурс не удалось?

Ох уж эти любители DoPostInit() и IsValid() А хранить код ошибки в каждом враппере - самый что ни есть pure C way

зачем IsValid() если есть explicit operator bool()?

std string и многие другие, bad_alloc. Это конечно скорее исключение :)

Ну и зачем мне не валидный объект нужен? да много кто: std::shared_mutex/semaphore, гварды,

исключение среди исключений)

Суть не меняется

а если его для логики работы ресурса нужно заиспользовать?

что?

Так если ты хотел перейти на std::expected, то подразумевается что нужен. Невалидный объект это другое агрегатное состояние std::expected<Obj, Error> с заполненным Error

например, врапер над каким-нибудь коннекшеном, И оператор bool, показывает живой ли коннекшн. Зачем отбирать возможность у логики в угоду обработки ошибок, если для этого есть соответствующие средства: exceptions, optional/expected

хех исключения не работают между потоками

Ну так не валидного объекта моего типа нет. Есть expected, который говорит, почему нет.

у меня лично мёртвый коннекшн это ВПОЛНЕ валидное состояние и его можно восстановить

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

так я не говорю, что это ошибка. Я говорю, что это логическое состояние ресурса, которое можно получить через bool оператор. А если мы его "отбираем" для ошибок конструирования, то как-то уже не очень. Но это уже на вкус и цвет.

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

я лично решаю эту проблему другим путём: конструирование никогда не завершается ошибкой

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

да, это Objective-C-стайл, но всё же

а критическая (пусть и не жёсткая) ошибка, из которой уже невозможно восстановиться?

Шоб у Вас в ядре ОС так ломали.

+1 А если нужно помимо состояния ("Failed", false) сохранить и код ошибки, и стек, и описание? Пихать все это в объект и хранить до востребования - плохая идея. Либо исключение из конструктора, либо Error в expected как отдельная сущность

а что делать, если таки должно завершаться ошибкой?

Вполне работают. Можно посмотреть на документацию std::exception_ptr и реализацию std::future или корутин.

это называется не работают()