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

Subject: Re: [boost] [outcome] outcome without empty state?
From: Andrzej Krzemienski (akrzemi1_at_[hidden])
Date: 2017-05-26 12:54:39

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
}
```

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.

Regards,
&rzej;