On Thu, Sep 10, 2020 at 1:38 PM Dusan Jovanovic (DBJ) via
Std-Proposals <std-proposals_at_[hidden]> wrote:
>
>
> Dear All,
>
> I would respectfully request your comments on R1:
> http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2020/p2192r1.pdf

TL;DR: This text better says what you're trying to propose, but what
you're trying to propose has no improvements from R0.

Editorial comments:

First, you're generally supposed to solicit mailing list feedback
*before* submitting it to the committee, not afterwards.

The proposal is better written than the previous one. There are actual
paragraphs and the line numbering is gone. It's much more
comprehensible as to what you're trying to do.

There are still some editorial flaws. There are some sentences that
seem incomplete or nearly correct, possibly due to unfamiliarity with
English. Usually you can work out the intent, but some of them make it
unclear exactly what is being said. For example:

> metastate also serves in coding clean algorithms for complex function call consuming

Function calls consuming what, exactly? Was there supposed to be more
of a sentence there? Or are you talking about some code which consumes
the results of "complex function calls"?

Oh, and you keep calling "metastate" a "paradigm". It's an idiom;
that's the right word for when a programmer repeats a pattern of code
to solve a common set of problems. "Output parameters" are idioms.

And stop calling the reader "honorable readership." Flattering the
user isn't going to improve the technical merits of your proposal.

Several times in the proposal, you use words which you feel must be
linked to their definition. Generally speaking, if you're using a word
that you feel you need to define, then you're using the wrong word (if
"tractate" is just a synonym for more well-known words, just use
them), are insulting the intelligence of your audience (thanks, but I
know what a panacea is), or are defining a term-of-art for your
proposal. Those first two alternatives are not generally good ideas.

Technical comments:

While it is better written, at the end of the day, it is still
proposing the same thing as R0. And thus it has all of the flaws of R0
as discussed in the previous thread:

* It specifies a type that provides no functionality that a user
couldn't get with 5 minutes of coding,
* which implements an idiom that is without meaning (the current
version even emphasizes that the very names of the metastates aren't
intended to have meaning, despite using words that very much do have
meaning),
* whose usage is simultaneously too flexible and too inflexible to
well cover the cases it seems to want to (ie: combining information,
status, and error in the same channel),
* and the majority of whose use cases are adequately covered by
existing solutions that provide equivalent if not superior
functionality and usability (expected, outcome, etc).

Basically, you haven't addressed any of the salient issues of R0.
Indeed, you've given `std::valstat` even *less* functionality:

> Both value and status type must offer an method[sic] that reveals their occupancy state. Presumably in a simple manner.

OK: what exactly is this "simple manner"? Is it that it must be
explicitly convertible to bool? If a user is getting a `valstat` type,
how does the user know how to use either of the two members to get
access to the actual data involved?

At least when you had `valstat` contain a pair of `optional`s, the
type was *usable*. It may have been bloated, but a piece of code could
actually use any `valstat` object it was given.

You've removed *basic usability* from this type.

You've created an interesting contradiction. In your effort to create
a type so easy to adopt that it would achieve widespread adoption,
you've made a type so bereft of functionality that *nobody would ever
adopt it*. If someone can't come up with a reason to use the metastate
idiom and/or the `valstat` type other than "somebody else is using
it", then it's a bad idiom/type.

Also, the sentence:

> This is not yet another error handling solution

feels decidedly unconvincing when the very next sentence contains a
reference to an *error handling solution*. It also feels increasingly
unconvincing when most of your points in your "Motivation" section are
allusions to various existing "error handling solutions".

I think a far more honest statement is what you say later:

> it is not just a solution for error handling

Namely, you admit that your proposal subsumes error handling, but is
not solely about that. That's different from declaring that it's not
"another error handling solution".

Similarly, it's hard to take this statement seriously:

> this proposal is not C++ language extension, or an[sic] "panacea" , "silver bullet", "awesome paradigm" and some such "revolutionary thing".

when it was immediately preceded by the definition of a "paradigm",
which includes:

> When you change paradigms, you're changing how you think about something...

That sounds pretty revolutionary to me.

There is a strange sense throughout this proposal of a weird cognitive
dissonance at play. You don't want it to appear revolutionary, because
then it would be highly scrutinized and you'd have to explain why the
`valstat` type does basically nothing at all. But because `valstat`
provides no functionality, the only reason anybody would ever use it
is if it were already in widespread use, so your primary impetus for
the type is that it's something people can adopt easily. But
widespread adoption requires a "revolution" of sorts in programming,
because people will have to take their currently functioning code and
make it use this. Which requires that it be easy to adopt, regardless
of whether it does something.

Similarly, you don't want it compared to error handling proposals
because they're all better at doing error handling than `valstat`. But
you can't ignore that the main use case for `valstat` is definitely
error handling, so you keep having to bring it up. Which undermines
the statement that it's not doing error handling.