Le 24/05/2017 à 21:43, Niall Douglas via Boost a écrit :
There has been a fair bit of review feedback that people don't like the formal empty state in outcome<T> and result<T>. I still think this opinion daft, just because it's there doesn't mean you have to use it, but here are some options:
1. Like Expected, we could require the E types to provide a nothrow move constructor. This would allow us to guarantee no empty state, not ever. Default constructing an outcome<T> or result<T> would set a default constructed T state, just like Expected. We could as well choose to don't initialize at all. I want to open this debate in Toronto.
The only remaining difference now between result<T> and expected<T> would be the wide vs narrow observer functions. outcome<T> still can also carry a std::exception_ptr.
2. We could do the above, but default constructor constructs to some constexpr undefined state that is not state T nor E. Agreed, we could as well choose to don't initialize it at all. I want to open this debate in Toronto. I don't want this to be observable.
3. We could only provide a guarantee of no empty state if the E types provide nothrow move construction, but if they do not we fall back to an empty state arising if throws occur during assignment. This is a *valueless-by-exception* as for variant. When do you want to report an error that has a move constructor that can throw? What would you report at the end. Sorry I can not report to you the reason for failure as an exception was throws while constructing the report :( If we want to KISS Error types must be no-throw movable.
4. The option for an empty state becomes a template parameter defaulted to false i.e. disabled. This can be combined with any of the above. No thanks.
I don't see yet the need for this empty state. Vicente P.S. I expect to have in C++20 a std::variant that don't have this *valueless-by-exception* state when the conditions are satisfied.