2017-05-26 0:17 GMT+02:00 Peter Dimov via Boost
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