Re: [boost] [system] Would it be possible to trial a breaking change to Boost.System and see what happens?

Subject: Re: [boost] [system] Would it be possible to trial a breaking change to Boost.System and see what happens?
From: Christopher Kohlhoff (chris_at_[hidden])
Date: 2018-01-14 04:05:14

Hi Niall,

> On 14 Jan 2018, at 11:27 am, Niall Douglas via Boost <boost_at_[hidden]> wrote:
> 
>> I appreciate that the special meaning of 0 may be undesirable
> 
> It's not just undesirable. It's incorrect. The present design precludes
> any third party error code domain which does not treat 0 as being
> success, or which treats values in addition to 0 as success, from being
> wrapped into an error code.

I have only skimmed this thread, but you appear to be operating under a misconception.

The error_code class itself deliberately does *not* imbue zero values with the meaning 'success' and non-zero values with the meaning 'failure'. An error_code simply represents an integer and a category, where the category identifies the source of a particular integer value. The specification of the error_code class carefully avoids making any judgement as to whether a particular value represents success or failure. The construct:

  if (ec) ...

does not, in and of itself, mean 'if an error ...'. Instead, operator bool is specified to behave as the ints do, and the above construct should simply be read as 'if non-zero ...'.

(N.B. I view the existence of boost::system::errc::success as vestigial. The enumerator does not appear in std::errc.)

Instead, the correspondence of particular error_code values to success or failure is context specific and is defined by an API. The filesystem and networking libraries do define zero to mean success, partly because they are specified in terms of POSIX operations that do likewise.

When defining your own API you are free to define your own notion of success or failure. One way would be to define your own error_condition for this (an intended use case for error_condition), but you may also use some other mechanism entirely (indicate failure via exception, return value, etc.). You might like to consider this approach for your own API that wraps NT kernel calls.

I suspect you may be coming unstuck because (unless I am mistaken) the expected and outcome classes have baked in the assumption that zero means success and non-zero means failure. This isn't the case for error_code itself.

[...]
> My intended proposal for WG21 is that when you compile code
> with C++ 23 or later, the new string_view signature takes effect. If you
> compile with C++ 20 or earlier, the string signature remains.

The use of string_view is a non-starter. It has unclear ownership semantics and does not cater to error sources that compose their messages on demand (e.g. messages that are obtained from another API function, read from a file-based catalog, or constructed based on an error code value that happens to be a bitmask).

Yes it would be nice to find a solution for error messages in freestanding environments that lack std::string, but string_view isn't it.

Cheers,
Chris