Re: [boost] [review] **NEXT WEEK** Review of Outcome (starts Fri-19-May)

2017-05-15 12:37 GMT+02:00 Peter Dimov via Boost :

Andrzej Krzemienski вроте:

...

vector os (20); // no value or error to assign yet

for (auto const& e : some_collection) if (cond(e)) os[i].set_value(); else os[i].set_exception();

.set_error presumably. (Incidentally, result<> is documented to have set_exception, which makes no sense to me.)

And in some cases, you cannot immediately rewrite the code in order to

...

avoid default construction. You do not want to return an "empty" object, but you need this value temporarily, end there may be no good value of `E` to use.

The argument that it's better to default-construct to some kind of a valueless state instead of T{} is legitimate, but even if I grant all the premises of that example (which is a stretch), I still don't see why default-constructing to make_error_code( outcome_errc::uninitiaized ) isn't better than special-casing the empty state.

Currently, if you are using library L, the `error_code` describes "disappointments" typical to L's business domain. And an empty `outcome` represents problems related to incorrectly using the Outcome library. IOW, getting and error_code` from library L indicates a robust design that takes into account any run-time situations related to managing resources or irregular user input, whereas an empty state indicates a bug in the code (you may use an empty state temporarily, but you shouldn't return it from the function). I think I am now saying something different than Niall, but that would be my conceptual model for this empty state. Also, to construct some object, it takes time. error_code is just two words, but why waste time on setting them if you will be overriding them in the course of the function call. And, in the current state you can perform a loss-less conversion (or "upgrade") form `option<T>` to `outcome<T>`. Regards, &rzej;