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

Subject: [boost] [system] Would it be possible to trial a breaking change to Boost.System and see what happens?
From: Niall Douglas (s_sourceforge_at_[hidden])
Date: 2018-01-12 17:43:27

SG14 the low latency study has been looking into how to improve some
design decisions in <system_error>. The relevant WG21 paper is
https://wg21.link/P0824 and recent discussion can be found at
https://groups.google.com/a/isocpp.org/forum/#!topic/sg14/j7tQybEjP5s.

What we'd like to do is to test whether some very mildly breaking
changes to <system_error> are so mild as to affect no users, and on that
basis propose WG21 to make those mildly breaking changes to
<system_error> in the next C++ standard. And to test this, we'd like to
modify Boost.System with those mildly breaking changes, ship a release
and see how many users complain. If it is zero, we have evidence for
WG21 that this is not a consequential change.

What we'd like to change is this:

1. Stop treating code zero as always meaning success irrespective of
category. This remedies a defect where some custom error code domains
cannot be represented by error_code due to using value 0 for an error.
In actual code, I've never seen anyone ever use comparison to anything
but a default constructed error code, so I think this will be safe.

2. Success becomes solely the default constructed error code, which is
code zero and a new category of "null_category". This is internally
represented by { 0, nullptr }, and thus makes the default constructor
trivial which is highly desirable as it eliminates any compiler magic
static fencing for the default constructor. Right now the default
constructor uses system_category with value 0, and I suspect no code
will notice this change either.

3, Make the default constructor constexpr, now possible. No code should
notice a difference, except less runtime code will be generated.

4. error_code::message() returns a std::string_view instead of
std::string if running C++ 17 or better. This lets us remove the
<string> dependency, and thus stop dragging in half the STL with
<system_error> which in turn makes <system_error> actually useful to the
embedded systems crowd. The guess here is that std::string_view has such
excellent interoperation with std::string that I think 99% of code will
compile and work perfectly without anybody noticing a thing.

I appreciate that this would undo Peter Dimov's excellent work at having
Boost.System alias <system_error> under C++ 11 and later. I also
appreciate that we are deliberately going to potentially break end user
code. But my personal guess is that in practice, the breakage will not
be noticed by 99% of code out there right now. It'll just compile
against the improved Boost.System and everything will work as before.

Boost was originally intended as an incubator for C++ standard changes.
This ticks that box perfectly.

Thoughts on feasibility?

Niall

-- 
ned Productions Limited Consulting
http://www.nedproductions.biz/ http://ie.linkedin.com/in/nialldouglas/