Re: [boost] [outcome] Requesting second pre-review of Boost.Outcome tutorial

Subject: Re: [boost] [outcome] Requesting second pre-review of Boost.Outcome tutorial
From: Andrzej Krzemienski (akrzemi1_at_[hidden])
Date: 2017-01-25 11:22:27

2017-01-25 14:56 GMT+01:00 Niall Douglas <s_sourceforge_at_[hidden]>:

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