On Thu, Jul 30, 2020 at 3:06 AM Dusan Jovanovic (DBJ) via
Std-Proposals <std-proposals_at_[hidden]> wrote:
>
> There is just a "conceptual mechanism" that is important.

The word you're looking for is "idiom". An idiom is a repeated pattern
of code applied to solve a specific problem. Iterators represent an
idiom. Your description below of "metastate" is an idiom.

> And yes, this "metastate" "conceptual mechanism" no one has published before. Thus it has nothing to do with anything in the same category, like expected or outcome are.

It doesn't really matter if someone has published the identical idiom
or not. An idiom, in and of itself, is worthless. What matters is what
problems a particular idiom solves.

Your idiom purports to solve the problem of functions that can errors
without having to use exceptions, alternate outputs through
parameters, or out-of-band error paths like globals. `expected` and
`outcome` also solve those problems.

Users can use `expected` and `outcome` to "produce a code that is
simple and resilient because it is "throw/catch free", does not use
<system_error> and allows for rich but local call handling." As such,
you therefore need to explain why your idiom is the better choice to
achieve these ends.

> Put in the code, metastate idea is really rather simple
>
> // wrong
> auto [value, error] = your_function ();
>
> // metastate
> auto [value, state] = my_function ();

Your proposal does not do a good job explaining why the first one is
"wrong". In fact, I don't recall anything in your proposal about why
that code is bad.

The closest you come to explaining this is citing P1677. But that
proposal is all about why it is a bad idea to use error channels of
*any* kind to report cancellation of an operation. P1677 argues that a
cancelation value ought to be considered a fundamentally different
thing from either erroring out *or* returning a valid value. That is,
it suggests a 3-state system, but it also suggests that these three
states need to be separate. Your idiom tries to combine them by
forcing the cancellation state and the error state to have to be the
same type, as well as the cancellation state to have to involve a
legitimate value as well.

So if we were to follow P1677, your idiom would look like this:

```
auto [success_value, cancel_value, error_value] = my_function();
```

Your "INFO" state is nothing like P1677's cancellation mechanism. So
I'm not sure why you brought it up as a justification for your
metastate idiom.

If you want a more succinct breakdown of the issues I have
specifically with metastate as an idiom, here they are:

1. The justification for why there needs to be an "empty" metastatic
is nonexistent. Why does every function that can error need to be
functionally capable of returning no value? Why does every piece of
code calling such a function need to test for the no-value case? And
if it's OK for a function to never return empty, and it's OK for the
caller of such a function to never test for empty... why should the
return type permit empty *at all*?

2. The justification for why you want to use the "status" channel to
mean "error" sometimes and "info" other times is also nonexistent.
Combining them makes it impossible to return info and error values of
different *types*. If the error value is a message, any info value
from that function also has to be a message. Why is this built into
your idiom? Similar to the above, why does every function that could
error also conceptually need to be able to signal a success+info
value? Most functions don't need to.

My general read of C++ functions is that most functions which can fail
do not need to return empty objects nor need to return objects and
info values. So why does your idiom *require* these additional states
if most functions are not going to actually use them?