On Thursday, 10 September 2020 10:37:23 PDT Dusan Jovanovic (DBJ) via Std-
Proposals wrote:
> I would respectfully request your comments on R1:
> http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2020/p2192r1.pdf

Hello Dušan

First reaction: are we in a constrained environment where we need to save on
keystrokes and symbol name length? If not, please find a more expressive name
than "valstat". It should give *some* idea of what the type is, preferably
with no contractions. "valstat" to me is a "value state" but that doesn't give
me any indication of what the type is meant to to. Unless "stat" refers to the
"stat" system call, but that makes even less sense...

When Brian Kernigham was asked what he'd do differently if he had do do Unix
all over again, he joked the only thing he'd do was "add an e to creat".

Instead, if the name "valstat" has roots in other libraries or languages where
this concept has been used, please list a few of them. They're clearly
unfamiliar to me. Having references like that would not only validate the
name, but also the interface and usage models. If instead you're coming up
with something new, please err on the side of being descriptive.

Your abstract should talk about the problem being solved too. it's too vague.

In your motivation, you mention 6 things that some projects are unable to use.
I recommend you explain why those are common issues, if you can. If not,
please explain the more obscure ones, with at least one sentence? For me,
that's why <system_error> is not an acceptable solution to many projects --
made worse by your use of std::errc in an example later. Also, please explain
how you can increase compatibility by adding a new type, that's counter-
intuitive.

It then says "Honourable readership is well aware of the reasons behind and
issues arising from this list". Since I am not well-aware of what you're
talking about, you're calling me dishonourable. So I should stop reading here.
Your summary also says "Author is certain honourable readership knows quite
well why is the situation unresolved, and which situation is that" which makes
it sound like this is a problem known to only certain people and the rest of
us don't need to know.

You're glossing over the requirements for the types: "Both value and status
type must offer an method that reveals their occupancy state." Can you give
examples? Can you give counter-examples too of types that cannot be used for
the value? For example, can I use an int where any value is valid? What if I
use a std::string? If those can't be used, what's my alternative?

Talking about alternative, can you add a section explaining other
possibilities that solve the same problem? Please compare to out-parameters
and to other solutions that return everything in the return type. And as much
as I hate std::pair, please explain why your needs can't be solved by
std::pair (an answer might be "std::pair is used for too many things, this
type is used to denote restricted semantics").

Finally, you may want to add a section of where this new type is not useful
and what library writers should use instead. If I understand you correctly,
it's useful when you have the 4 possible states you listed. But most error-
returning code I am aware of can either return a value or an error, never
both. Is there a better solution than your type for this? Your example of
modern_fopen is actually one so: it either succeeds with an open file or it
fails, reporting why. Knowing that, it's possible to have a return type that
is even more efficient.

PS: You linked to the dictionary definition of "tractate". If you had to do
that, it means you chose the wrong word.

-- 
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
   Software Architect - Intel DPG Cloud Engineering