Re: [boost] [outcome] outcome without empty state?

Subject: Re: [boost] [outcome] outcome without empty state?
From: Vicente J. Botet Escriba (vicente.botet_at_[hidden])
Date: 2017-05-26 14:44:16

Le 26/05/2017 à 14:54, Andrzej Krzemienski via Boost a écrit :
> 2017-05-26 6:53 GMT+02:00 Vicente J. Botet Escriba via Boost <
> boost_at_[hidden]>:
>
>> Le 26/05/2017 à 00:52, Gavin Lambert via Boost a écrit :
>>
>>> On 26/05/2017 00:30, Peter Dimov wrote:
>>>
>>>> Vicente J. Botet Escriba wrote:
>>>>
>>>> I need a default constructor even if uninitialized.
>>>>> What do you think an uninitialized default constructor?
>>>>>
>>>> Awful, of course. Gratuitous undefined behavior is never good.
>>>>
>>> +1
>>>
>> After some exchanges with Jonathan I believe now that we shouldn't have
>> the uninitialized default constructor.
>> My arguments were wrong and this makes the implementation less efficient
>> and more complex.
>>
>> So either we have the status-quo or we delete it.
>>
>> I start to think that maybe the best would be to remove it :(
>>
> Let me just recall her the suggestion from Peter made in the other thread.
> Mybe have two types:
> `expected<T, E>` does not have the empty state or default constructor -- it
> is used as function's return type
> `prepare_expected<T, E>` is either T or E or Empty -- you use it inside
> function to build expected<T, E>:
>
>   ```
> expected<T, E> f()
> {
>    prepare_expected<T, E> ans;
>    // populate (or not) ans
>    return ans; // in this conversion you can do all sorts of checks
> }
> ```
  The kind of code that declares a variable and then populate or not 
something can always be refactored to a smaller function that returns 
the value to initialize the variable.
See C++ guidelines. Declare as close as possible -> then initialize at 
the declarations -> then declare it const if not modified elsewhere.
What is wrong by returning just expected when you know the result.

> When it comes to converting from `prepare_expected<T, E>` to `expected<T,
> E>`, you have plenty of choices: require manual conversion, narrow-contract
> to be checked, a defensive if and throw... I am just not sure if
> performance can be negatively impacted with this.
>
I suspect that there will be a performance impact. Whether it is minor 
or not would depend on the context.

Vicente