Re: [boost] [outcome] Possible extensions/changes to std::experimental::expected

Subject: Re: [boost] [outcome] Possible extensions/changes to std::experimental::expected
From: Peter Dimov (lists_at_[hidden])
Date: 2017-05-25 22:17:03

Andrzej Krzemienski wrote:

> Also, they way I look at this solution is not "when I get this value I 
> have to check ...", but "when I produce this value I have to make 
> sure...". Is there no way to acheive this in the language?

By not providing a default constructor, I suppose. Otherwise not, there's 
return value elision so if you do

result<T> function()
{
    result<T> r;

    // do things

    return r;
}

nothing is ever called on 'r' on your side if you forget to initialize it.

Putting "outcome_errc::not_initialized" inside r made sense, because the 
principle is that when the returned result has no value, it has to contain 
the reason for its failure to contain such, and here the reason is that 
whoever wrote the function left it uninitialized. This looks logical to me, 
apparently to others not so much.

It's not really that much different from returning EINVAL in r because the 
programmer made some other kind of logic error - instead of forgetting to 
initialize r, he forgot to initialize some argument to some lower level 
function he called, so it returned EINVAL and that's what ended up in r.