Hi Jason,
many thanks for the comprehensive critique on style especially. It will shape the R1 certainly.
now ... the core idea is "metastate" .. it has nothing to do with C++20 "concept"'s. function return metastate is not a state .. state would be "error or no error". one can capture it, but
metastate is not a type. perhaps I should use the synonym: "theory" or simply "core idea".
FWIW: Now that C++20 has taken the English word "concept" from us, I have started to use the English word "notion" to describe ideas in the abstract sense, e.g. "the notion of an iterator" or "the notion of type erasure" or "the notion of functional programming." The English word "idea" also works. I would avoid "theory" unless you mean it in the scientific sense (i.e., a hypothesis supported by evidence).
I only glanced at the first page of your paper and don't plan to read it, but everything Jason said sounded reasonable to me. I infer that you're proposing to replace std::expected/Boost.Outcome with something like std::pair so that it can be destructured easily, and that doesn't sound to me like a good idea at all.
If destructuring is your main concern, have you looked at the ongoing "pattern-matching" proposals? If pattern-matching permitted you to destructure a std::expected more easily, would your "valstat" idea lose its main motivation?
Technically std::valstat" is just a meta state carrier (an vehicle). Implemented in C++ using C++ std lib.
It is equally valid (aka "core idea compliant") to implement it in C ... as the article shows. Or any other imperative language. One can imagine the whole new CRT implementation using the valstat core idea.
What do you think on other benefits of using metastate (aka valstat) like "no exceptions"? I might say "no exceptions for free". What do you think of the attempt to conform to the P2000R1 recommendations?
All that P2000R1 says on the subject of "no exceptions" is:
> To make progress, we need better data on costs and performance to evaluate the
> - often simplistic and narrowly focused -
solutions suggested. Without better data
> and analysis, we risk hitting the N+1 problem ("the
problem is that we can't
> manage N alternatives, so we add a new and better solution, thus
having to
> deal with N+1 alternatives")
–Arthur