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-25 22:40:45

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

True. This is off topic, but maybe the future language should add something
to protect against spillint the default-constructed value (at least of some
types) to deep into the program. I do not know how. But this problem often
occurs and is not limited to `outcome` or `expected`.

>
> 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 will work for result<T>, because it has to store "any error
whatsoever", but will not for expected<T, E>, where E is an enum of two
values: too_little, and too_big.

Regards,
&rzej;