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: Edward Diener (eldiener_at_[hidden])
Date: 2018-01-12 20:38:36

On 1/12/2018 12:43 PM, Niall Douglas via Boost wrote:
> 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.

The usual way is to announce the upcoming change in release nnn and then 
make the change in release nnn + 1. What is wrong with using this method 
in your case, if all parties are in agreement to do it ?

> 
> 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
>