*Many thanks for the time spent on this. My answers are inline.*

On Fri, 11 Sep 2020 at 00:56, Jason McKesson via Std-Proposals <
std-proposals_at_[hidden]> wrote:

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

*DBJ > That was my aim*

but what you're trying to propose has no improvements from R0.
>
*DBJ > Yes, The theory and its implementation are not changed. *

>
> Editorial comments:
>
> First, you're generally supposed to solicit mailing list feedback
> *before* submitting it to the committee, not afterwards.
>
*DBJ> I understand. I am seeing all of this as a discussion before the
final release.* *This is important since I can clearly see where do I fail
to explain important points and where do I keep explaining things that need
no explaining.*

>
> 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.
>
*DBJ > Thanks. Few other "followers" independently of each other were
asking for more examples. Thus I developed a little non-trivial project
trying to clarify things in the real-life situation.
Here: https://github.com/dbj-systems/libstdc-error/tree/crt_proxy_lib
<https://github.com/dbj-systems/libstdc-error/tree/crt_proxy_lib> . Please
do let me know if you have found some usefulness in there.*

>
> There are still some editorial flaws. There are some sentences that
> seem incomplete or nearly correct, possibly due to unfamiliarity with
> English.

*DBJ > I shall aim to correct those *

> Usually you can work out the intent, but some of them make it
> unclear exactly what is being said.

*DBJ> Huh, I do agree.. *

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"?
>
*DBJ > My bad perhaps. "consuming the API call" ** means "non-trivial
function result processing. That was in English, I hope :)*

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


> *DBJ > I understand. I think there is "paradigm" and there is "idiom" in
> here. "... A paradigm is a way of looking at something ... When you change
> paradigms, you're changing how you think about something..." vocabulary.com
> <https://www.vocabulary.com/dictionary/paradigm>*

* I also think of "metastate" as "paradigm shift".I might think "valstat"
produces an idiom? A good example is "canonical metastate capturing" (I was
about to type "consuming" ;) * *The doc section 3 has the code that is an
"idiom".*

*DBJ> At this point I have given up replying to every sentence*

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

* DBJ > Basically imagine the existence of a generic but implemented
function -- is_empty( container_of_one ) -- that is in a simple manner
letting us know what is the state of occupancy. See this is the value of
debate. I just realised the "container_of_one" is the valuable name in the
context of C++ forum. In database theory this is known since 50-es as
"field". "field" in db is what "container of one" in C++ is. std::optional
is a container of one.*

*DBJ> std::valstat is completely generic aka the "transparent type". in the
context of C++ it seems it is best implemented using std::optional. An
issue is a lot of projects
<https://github.com/dbj-systems/libstdc-error/tree/crt_proxy_lib/crt_proxy_lib>might
not have std::optional, because in there, there is no std lib. no
"expected" and no "outcome". Still, they might (or will) benefit from the
"metastate" as a paradigm and from "valstat" leading to an "idiom".*

*DBJ > crt_proxy_lib
: https://github.com/dbj-systems/libstdc-error/tree/crt_proxy_lib/crt_proxy_lib
<https://github.com/dbj-systems/libstdc-error/tree/crt_proxy_lib/crt_proxy_lib>
.
"metastate" + "valstat" achieve the "returns handling" minus complex and
special return types. I am simply postulating expected, outcome and the
rest, are not required. Also too complicated and narrowly focused on C++,
in modern projects where C++ is just a tiny part of the architecture of a
cloud-side system. As an architect, I can jump in and out of different
languages but keeping the same "idiom"(valstat) or "paradigm" (metatstate).
Think WASM combination of javascript, C and C++. In all three I can (and
will) deploy the form of valstat. Here it is. I have said it :) *

*DBJ> I have a question or two, if I may? What is your advice for projects
from the motivation section? And. What is your advice for (let's say) C++
projects using std lib, regarding "error handling" design? *

*Kind regards ...*

-- 
> Std-Proposals mailing list
> Std-Proposals_at_[hidden]
> https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals
>