2017-05-31 16:26 GMT+02:00 Peter Dimov via Boost
Gavin Lambert wrote:
I probably should have thought of asking this earlier, but it occurs to me now that my own mental model of how an "outcome"-ish type should act is probably not suited to variant storage at all.
So just out of curiosity I thought I'd ask whether people prefer this sort of interface:
...
Or this sort of interface:
...
Neither. I prefer a combination of the two. Like a variant, exactly one of has_value(), has_error(), has_exception() should report true, depending on whether you called set_value, set_error, or set_exception. The accessors however, should work as you previously outlined.
// throws when !has_value() T value() const;
// error_code() when has_value() // error when has_error() // errc::has_exception when has_exception() error_code error() const noexcept;
What when `if_empty() == true`?
// nullptr when has_value() // either nullptr or make_exception_ptr(system_error()) when has_error() // exception when has_exception() exception_ptr exception() const noexcept;
What when `if_empty() == true`?
Proposed additional narrow:
// nullptr when !has_value(), otherwise &value_ T* operator->() noexcept; T const* operator->() const noexcept;
This is not narrow: this is wide. I disagree.
// *operator->() T& operator() & noexcept; T const& operator() const & noexcept; T&& operator() && noexcept; T const&& operator() const && noexcept;
This is operator*, right? This is technically narrow, but without essential benefits of direct narrow contract, as I tried to explain in another thread. I disagree.
value() can also have the four-overload form, not shown for brevity.
Is there anyone that objects to that model?
Yes, it des not offer a *proper* narrow contract.
I am sympathetic to people's desire to have a statically checkable value accessor, but I see no reason to provide such for error() or exception().
I am not sure about this. I have no strong opinion at this point.
The "exactly one is true" requirement allows all possible checks to be expressed in a concise manner. If you want to test for error or exception, say, that's !has_value.
What about is_empty()? Or are we considering the type without empty state? Regards, &rzej;