This looks familiar.
Did you have a look at std::expected (P0323)?

https://wg21.link/p0323r3

Dusan Jovanovic (DBJ) via Std-Proposals <std-proposals_at_[hidden]>
schrieb am Do., 10. Sept. 2020, 23:20:

> 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
>>
> --
> Std-Proposals mailing list
> Std-Proposals_at_[hidden]
> https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals
>