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-06-01 07:03:29

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

> Andrzej Krzemienski wrote:
>
> What when `if_empty() == true`?
>>
>
> Nothing, I don't have an empty state.
>

Ok. Not having an empty state would work for me. I am not sure about others.

>
> > 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.
>>
>
> Why do you 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.
>>
>
> What essential benefits are lost?

I tried to outline my reasoning in this post:
http://boost.2283326.n4.nabble.com/outcome-narrow-contract-wide-contract-and-value-if-td4695003.html

In short, when the narrow contract is directly in the library's interface,
I have a place where I can put BOOST_ASSERT(), or similar code for
assisting instrumented builds.

In what you propose, the library has a wide contract, it returns another
type (pointer) with a narrow contract; but it is somebody else's narrow
contract and I cannot put this librarie's sanity checks.

Let me just mention here that the LWG recommendation, while it probably
makes sense for the Standard Library description, is not necessary in
Boost. We can just make narrow-contract functions noexcept.

Regards,
&rzej;