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

If it helps there is a non-trivial project 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@lists.isocpp.org> 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@lists.isocpp.org
https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals