Approximate map between error code designs - Boost.Outcome documentation

# Approximate map between error code designs

Much of the design of Boost.System (which went on to become `<system_error>`) has been retained in proposed `<system_error2>`, so an approximate map between `<system_error2>` and `<system_error>` and Boost.System can be given:

C++ 17 `<system_error>` | Boost.System | Proposed `<system_error2>`
--- | --- | ---
`std::errc` | `boost::system::errc` | `experimental::errc` (almost identical)
`std::error_category` | `boost::system::error_category` | `experimental::status_code_domain`
`std::generic_category` | `boost::system::generic_category` | `experimental::generic_code_domain`
`std::system_category` | `boost::system::system_category` | One of: `experimental::posix_code_domain` (POSIX systems) `experimental::win32_code_domain` (Microsoft Windows) `experimental::nt_code_domain` (Microsoft Windows) Note that there are more precanned code categories though they require additional header inclusions: `com_code`, `getaddrinfo_code`.
`std::error_condition` | `boost::system::error_condition` | No equivalent (deliberately removed as hindsight proved it to be a design mistake leading to much confusing and hard to audit for correctness code)
`std::error_code` | `boost::system::error_code` | One of: `experimental::status_code<DomainType>` `const experimental::status_code<void> &` `experimental::status_code<erased<intptr_t>>` (aliased to `experimental::system_code`) `experimental::errored_status_code<DomainType>` `const experimental::errored_status_code<void> &` `experimental::errored_status_code<erased<intptr_t>>` (aliased to `experimental::error`) The difference between status codes and errored status codes is that the latter are guaranteed to refer to a failure, whereas the former may refer to a success (including warnings and informationals).
`std::system_error` | `boost::system::system_error` | One of: `const experimental::status_error<void> &` `experimental::status_error<DomainType>`

As is obvious from the above, in `<system_error2>` one must be much more specific and accurate with respect to intent and specification and desired semantics than with `<system_error>`. Much ambiguity and incorrectness which flies silently in `<system_error>` will refuse to compile in `<system_error2>`.

Last revised: December 16, 2020 at 14:14:42 UTC