Re: [boost] [outcome] Ternary logic -- need an example

Subject: Re: [boost] [outcome] Ternary logic -- need an example
From: Andrzej Krzemienski (akrzemi1_at_[hidden])
Date: 2017-05-19 22:35:18

2017-05-20 0:03 GMT+02:00 Niall Douglas via Boost <boost_at_[hidden]>:

> >>> A program might return an outcome containing a null
> >>> error_code. It probably is a bug,
> >>
> >> Interesting. I need to think about it. But my first response would be.
> If
> >> a user cheats the system in this way, you should not try to rescue the
> >> situation.
> >
> > I can think of two ways of looking at the situation with a
> > value-initialized error code:
> >
> > 1. Class outocme<T> has an invariant: putting it into state where it
> stores
> > a value-initialized error code is a bug, close to undefined behavior,
> which
> > means, you can assert() inside and users and algorithms  can expect it
> > never happens.
>
> I am afraid I don't understand. A value initialised error code is surely
> a normal error code? Why would I need to assert stuff?
>
> > 2. Class outcome<T> can be in yet another state: "strange". So we have
> the
> > following states: valued, exceptional, errored, empty, and strange. And
> the
> > user when inspecting the state has to take into account all the five
> > possible states.
>
> Every additional possible state generates more branches for the
> compiler's optimiser to deal with. I would therefore reject any
> additional possible states.
>

I am not trying to propose any new logic here. I am trying to assign some
mental model to what `outcome<T>` currently does. Consider: some funciton
`f` is supposed to compute an `int`. But the computation may fail, in this
case I want the function to return the reason why it failed. Also, it is
possible that I will get some "internal error". For this reason funcio `f`
returns `result<T>`:

```
result<T> r = f();
```
Now, `r` can represent the following states:

```
if (r.has_value()) // value successfully computed
  {}
else if (r.empty()) // internal error
 {}
else if (r.error()) // reason why f failed
 {}
else if (r.has_error() && !r.error()) // what is that???
 {}
```

The last case is neither a value, nor a reason for failure, nor an
"internal error". How should a caller interpret it? Two possible answers:

1. There is a fourth state with no intuitive or sane interpretation.
2. Assume this never happens. If it happens it is a bug in calle site that
needs to be fixed.

Regards,
&rzej;