2017-01-25 14:56 GMT+01:00 Niall Douglas <s_sourceforge@nedprod.com>:
If your irritation is now improved, what do you think of the new and completely rewritten for a third time tutorial part A at https://ned14.github.io/boost.outcome/md_doc_md_02-tutorial_a.html. Part A is 100% a tutorial on LEWG Expected and has nothing to do with Outcome at all. Part B will be on why you shouldn't do all the things you think you should do with expected<T, E>, and why to use Outcome instead. Part B is still a work in progress.
Ok, so I had a short glimpse at Part A. Actually, the first thing I did was to scroll down to the example showing how I will be using this library. Again, I feel uncomfortable about the choice of the example (so I changed the irritation into non-comfort). The situations that are tested, I would classify them as precondition violations, and I wouldn't think of checking them in return value. If this was a real program, and I didn't trust the values of x and y, I can check the preconditions prior to invoking functions: ``` double op(double x, double y) { if (y == 0.0) // or "close { std::cerr << "PANIC: MatchResult::DivisionByZero" << std::endl; std::terminate(); } double ratio = unchecked::div(x, y); if (ratio < 0.0) { std::cerr << "PANIC: MatchResult::NegativeLogarithm" << std::endl; std::terminate(); } double ln = unchecked::ln(ratio); if (ln < 0.0) { std::cerr << "PANIC: MatchResult::NegativeSquareRoot" << std::endl; std::terminate(); } return checked::sqrt(ln); } ``` I mean, if it is equally easy to check the condition before and after the function, it is better to do it before, and I do not have to "pollute" the return value with potential error conditions. I think the value of these expected<> types becomes clear, when we cannot see the erroneous situation from the arguments. Maybe a better illustration of expected<> with a code would the following situation: Upon closing the application, I store its state in a text file. When I reopen the application the next time, I load the state from the file. Here is the function: expected<state, error_conditions> state = load_state(); And now, the error conditions are: * file missing * file is not a text file * file contains erroneous contents And I might want to respond to each of these conditions in a different way. Regards, &rzej;