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

Subject: Re: [boost] [outcome] Possible extensions/changes to std::experimental::expected
From: Andrzej Krzemienski (akrzemi1_at_[hidden])
Date: 2017-05-26 08:52:08

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

> 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.
>

This is only one way of looking at it. Another one is that I have function
like, `open_file`, I want it to either return the file handle or the
information about run-time situation that prevented opening the file.
"reading from uninitialized `expected`" is no such situation: it is simply
a bug. In this sense I consider Niall's choice better: just throw, even if
it means to terminate().

Regards,
&rzej;