I am sorry but I am unable to connect your comments to P2192R1?

If it helps there is a non-trivial project
<https://github.com/dbj-systems/libstdc-error/tree/crt_proxy_lib> using the
"metastate" paradigm. Project is about light C++ proxy API to the CRT
behind. Currently, only part of string.h is implemented.

Thank you ...

On Thu, 10 Sep 2020 at 21:13, Andreas Ringlstetter via Std-Proposals <
std-proposals_at_[hidden]> wrote:

> The "info" state somewhat misses real life use cases and ignores learned
> behavior on developer site. To name it, everything returned "informational"
> on such a channel is easily discarded as noise, as it adds significant
> bloat on each call site to handle it.
>
> At the same time, it builds on the (wrong) assumption that there is only a
> single non-fatal error or warning in a single function call.
>
> That be said, trace information does not belong mixed in with status
> information which *require* handling, ever. The only proper way to handle
> trace infos across components is by error reporting callbacks, anything
> else looses too much context to be of any real use.
>
> Treating the combination of `status && !value` as an error conflicts with
> real world APIs which have to distinguish between "please retry" and "fatal
> error". Both carry status codes, neither carries a value yet, but only one
> is an error.
>
> When using classic error codes with return parameters, `[[nodiscard]]` is
> suitable to enforce handling at the call site, when mixing value and status
> in a single return value, status code handling is likely to be missed by
> accident. And in a way which is quite difficult to enforce at compile time.
>
> I'm not quite sure on this point, but I also believe that interface is a
> bad substitute for interfaces which returned value "by value" in raw form
> (with use of exceptions), as it breaks copy ellision by that temporary
> wrapping even if the status code is intentionally discarded at the call
> site, due to error state being an impossibility in a fully controlled
> environment.
>
> Then there is also feedback from practical application of a similar
> pattern:
>
> Strict typing is essential, even for return values. Especially if the
> actual return value is just a primitive type wrapped in a future, stored
> for consumption in a different context, and mix-ups could easily occur
> otherwise. So you end up declaring return types with identical layouts as
> you go, at the cost of 5 LoC. Using your proposed template simply doesn't
> work, as you suddenly require more care to prevent specializations from
> being accidentally casted between each other, when inheriting publicly.
>
> Last but not least: the proposal is coming a bit late to the party.
> Unified error handling is something which would had been required before
> libraries had established their own standard ways. Now it falls in the line
> of "There are 10 competing standards. That's too many, let's design one
> which covers everyone's needs. Now there are 11 competing standards." There
> is no chance of unifying that aspect in the ecosystem retroactively.
>
>
>>
>> --
> Std-Proposals mailing list
> Std-Proposals_at_[hidden]
> https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals
>