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