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.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk