Re: [boost] [review] Review of Outcome (starts Fri-19-May)

Subject: Re: [boost] [review] Review of Outcome (starts Fri-19-May)
From: Peter Dimov (lists_at_[hidden])
Date: 2017-05-21 13:39:36

Niall Douglas wrote:
> > The vast majority of your user base may change if your library is 
> > accepted. It almost certainly will.
>
> I would still expect a vast majority to not want a Boost dependency.

The vast majority get their Boost libraries through some form of a Boost 
release. For them, the phrase "a Boost dependency" makes no sense at all. 
You could legitimately talk about depending (or not depending, which is 
preferable) on a specific Boost module, but not depending on Boost in 
general has no meaning when you're part of Boost in general.

> People want C++ 14 libraries to use the C++ 14 STL, not Boost,

Not a problem at all here, but not what we're talking about. You've 
eliminated a dependency on Boost, but substituted a dependency on something 
called Boost Lite. For people who acquire your library as part of Boost, 
this is not an asset, it's a liability. (For those who don't, it's vice 
versa.)

> Including Outcome does not include <windows.h>, except on winclang

Yes, I happened to have my toolset set to Clang.

> I should mention that boost-lite derives its macros from the C++ 17 
> feature macros, which all recent editions of major compilers support even 
> in C++ 14 mode.

Does MSVC support SD-6 macros? I thought that it didn't.

> The tutorial covers the need in real world code to attach some sort of 
> payload to error codes. Outcome provides error_code_extended with a 
> reasonable set of the most common likely payloads.

Yes, the need to attach more information to error codes is genuine. For 
exceptions Boost.Exception lets us do that non-intrusively, but for error 
codes we do not have a similar framework.

Speaking of which, can you please give me a few examples of what goes into 
the two codes (code1 and code2)?

> I would add that if you do not use any of the payload, error_code_extended 
> is identical to an error_code, no overhead.

Apart from the additional size_t. But it occurs to me that you can hide that 
on x64 if (a) you make it 32 bit - should be enough for a ring buffer - and 
(b) you do not derive from std::error_code but instead store the members 
directly in the correct order.

    int32_t cookie_;
    int value_;
    std::error_category const * cat_;

> I'll leave it to reviewers to decide on whether defaulting to the C++ 14 
> STL std::error_code or to boost::error_code is the most appropriate.

I'm not sure you understand me here... I'm saying that there's no need to 
default to boost::error_code or even keep the stl11:: way of choosing 
between the two.