Subject: Re: [std-proposals] P2192R0 -- Transparent return type
From: Arthur O'Dwyer (arthur.j.odwyer_at_[hidden])
Date: 2020-07-29 11:29:17
On Wed, Jul 29, 2020 at 7:23 AM Dusan Jovanovic (DBJ) via Std-Proposals <
> 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
> 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
> - often simplistic and narrowly focused - solutions suggested. Without
> and analysis, we risk hitting the N+1 problem ("the problem is that we
> manage N alternatives, so we add a new and better solution, thus having to
> deal with N+1 alternatives")
STD-PROPOSALS list run by herb.sutter at gmail.com
Standard Proposals Archives on Google Groups