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

2017-05-26 6:53 GMT+02:00 Vicente J. Botet Escriba via Boost < boost@lists.boost.org>:

...

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` does not have the empty state or default constructor -- it is used as function's return type `prepare_expected` is either T or E or Empty -- you use it inside function to build expected:

``` expected f() { prepare_expected 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

Le 26/05/2017 à 14:54, Andrzej Krzemienski via Boost a écrit : 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` to `expected`, 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