Re: [boost] [outcome] Ternary logic -- need an example

Subject: Re: [boost] [outcome] Ternary logic -- need an example
From: Vinnie Falco (vinnie.falco_at_[hidden])
Date: 2017-05-20 14:17:04

On Sat, May 20, 2017 at 3:12 AM, Bjorn Reese via Boost
<boost_at_[hidden]> wrote:
> When I perform an asynchronous HTTP operation that returns an error_code
> then I prefer that the error_code contains a unified response, i.e. an
> HTTP status code, a system error code (e.g. network problem), or an
> internal library error code.

I should have taken a bit more time before sending my reply -
apologies. I am bursting with things to say about this subject as you
can imagine so I will elaborate.

Consider the following:

    f is a function
    r is an unspecified result of performing some calculation on m
    m is an HTTP response message

    r = f(m)

If the calculation of r depends on the HTTP status, your proposal to
shove the status into an error_code would require:

    r = f(m, ec)

Where ec is an error_code. This introduces a problem, because now ec
can contain things that are not HTTP status codes, such as
boost::asio::error::connection_reset. f might not want or need to
handle metadata about the TCP/IP connection or other errors that are
not status codes. Now consider this:

    g is a function
    m' is an HTTP response message

    m' = g(m)

This example uses a functional style where a message m is transformed
by a function g into a new message. If we put the HTTP status in an
error_code not part of m or m', the signature would look like this:

    pair<m', error_code> g(m, error_code);

This signature imposes unnecessary burden on callers. It is also
confusing. Does the error_code in the return value indicate that g can
fail?

I hope readers are convinced that HTTP requests and responses should
be modeled as self-contained objects with all necessary fields
prescribed by rfc7230, and that the HTTP status should be neither
separate nor stored in an error_code.