Re: [boost] [outcome] To variant, or not to variant?

Subject: Re: [boost] [outcome] To variant, or not to variant?
From: Andrzej Krzemienski (akrzemi1_at_[hidden])
Date: 2017-05-31 15:04:20

2017-05-31 16:26 GMT+02:00 Peter Dimov via Boost <boost_at_[hidden]>:

> 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;