Re: [boost] [system] The new Boost.System is now ready

Subject: Re: [boost] [system] The new Boost.System is now ready
From: Niall Douglas (s_sourceforge_at_[hidden])
Date: 2018-10-09 08:56:54

>> The default implementation comes into play in a scenario in which the
>> client has "upgraded" to the new overload, but the (third party -
>> system and generic are already up to date) category hasn't, and I've
>> decided to preserve the message as much as possible rather than to
>> enforce the "no allocation" property at the expense of losing the
>> message. Maybe this is not the correct choice, I'm not sure. But
>> again, this scenario should eventually never occur as third-party
>> categories are updated.
> 
> I'm not sure either (so I hope that others chime in with their thoughts
> -- especially Niall, since he's worked with many of the people who I
> imagine would have strong opinions one way or the other).

I think Peter's choice is reasonable, given the constraints in play. But
I also think the system_error design can only have its rough edges
smoothed. It cannot be rescued. Peter disagrees.

I've got a fair number of users using the SG14 v2 system_error design at
https://github.com/ned14/status-code, some of which informed Peter's
improvements of Boost.System. Once they wrap their heads around the
weird template inversion, feedback has been universally positive. People
just love the arbitrary payload facility, and the way it can be type
erased and restored if all the constraints are met. They also like the
zero allocation defaults, and not dragging in any heavy STL headers. You
must explicitly opt in to allocation, unlike Boost.System.

Still, WG21 have not yet judged SG14 v2 system_error. Until they do, we
cannot know where it will go.

Niall