imagine we are developing only in C11. we will still use the "metastate"
paradigm. and we will simply return struct made of two pointers. (less than
a minute Jason :) ...std::valstat is just an ISO C++ form. Lets imagine
there are three companies: jason, dbj and dejan. al of them could use
std::valstat but jason::valstat will do and dbj::valstat will do etc ...

Customers will be all handling the returns (not just errors) in the same
uniform "metastate" way. coming from both jason or dbj API's. And if dejan
delivers his metastate enabled API written in C, customers will add and use
that too completely transparently as far as returns handling are concerned.

Customers, could be a team writing a medical device OS or a team writing
fast transaction server in C++. Or even be node.js team working in
javascript.

Returns handling "idioms" and a "paradigm"/"architecture" sorted for all.
So that all can concentrate on other things.

Architecture is what matters. Implementation comes second. jason is an
example of the universally adopted format for messages. "metastate" I
propose as a universally adopted paradigm for returns sending and returns
consuming. It is applicable on all level, from your medical device code all
the way to inter-system cloud situations.

Thanks for reading ...

On Sat, 12 Sep 2020 at 23:33, Jason McKesson via Std-Proposals <
std-proposals_at_[hidden]> wrote:

> On Sat, Sep 12, 2020 at 12:18 PM Thiago Macieira via Std-Proposals
> <std-proposals_at_[hidden]> wrote:
> >
> > On Friday, 11 September 2020 02:18:45 PDT Dusan Jovanovic (DBJ) via Std-
> > Proposals wrote:
> > > An
> > > issue is a lot of projects
> > > <
> https://github.com/dbj-systems/libstdc-error/tree/crt_proxy_lib/crt_proxy_l
> > > ib>might not have std::optional, because in there, there is no std lib
> >
> > That's not an argument. You can't add a type to the standard library
> because
> > there are projects that can't use types in the standard library. Either
> they
> > can use the standard library, in which case the existing types can be
> used, or
> > they can't, in which case they won't use your proposed type either.
>
> I'm fairly sure that the OP is referring to freestanding
> implementations. `std::optional` is not required, but many other types
> are required to be provided by such implementations. Presumably
> `std::valstat` would be required (despite being something you could
> write in 1 minute).
> --
> Std-Proposals mailing list
> Std-Proposals_at_[hidden]
> https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals
>