Re: [boost] [outcome] non-interface-related concerns

Subject: Re: [boost] [outcome] non-interface-related concerns
From: Niall Douglas (s_sourceforge_at_[hidden])
Date: 2017-05-27 14:40:51

>> I have also received quite a bit of private email begging me to keep
>> Outcome free of a hard Boost dependency if accepted. I have asked them
>> to say this publicly here, but I would assume they cannot for some
>> reason or other. Quite a few talked about how their multinational's
>> processes would find a standalone Boost.Outcome much much easier to deal
>> with than one with dependency on other Boost libraries. Some of those
>> are household name multinationals, and what they report matches my
>> experience at BlackBerry.
>>
> 
> This probably deserves a separate thread. My understanding is that we have
> three expectations:
> 
> 1. Boost developers do not want duplication in Boost.

Some Boost developers are ideologically and irrationally attached to
"how things are done around here", yes.

I don't know about not wanting duplication in Boost. There is a ton of
duplication in Boost. It's been waved through in peer review many times
in the past.

> 2. Non-boost users of Outcome do not want a dependncy on Boost.

Actually there is overwhelming evidence that Boost **users** do not want
a dependency on Boost. But I've been saying that for years now.

> 3. Niall does not want to maintain two nearly identical libraries.

I still hold open the offer of a fully Boost flavoured edition of
Outcome. I think it a mistake personally, but the offer is there. I've
given up on trying to instil awareness of the end user experience of
Boost into people on boost-dev.

>> Mingw is not a regularly tested platform, and hence is not advertised on
>> the documented compiler support page. Last time I tested it was well
>> before Christmas.
>>
> 
> Hold on. This is the page you are referring to:
> https://ned14.github.io/boost.outcome/prerequisites.html
> 
> It says:
> 
>> Outcome is a header only C++ 14 library known to work on these compilers
>> or better:
>>
>>    - clang 3.5 (LLVM)
>>    - clang 3.7 (with Microsoft Codegen)
>>    - GCC 5.4
>>    - VS2015 Update 2
>>    - Xcode 7.3
>>
> It does not mention explicitly that it does not support MinGW. Now, MinGW,
> according to my knowledge, is not a compiler but a platform on which a
> compiler works. On MinGW I am using compiler GCC 6.3.0, and this compiler
> is supported (Or not? -- you are ony mentioning GCC 5.4). This has been
> always my understanding of what MinGW is.

That's a very fair observation. I have updated develop branch to
indicate what compiler-platform combos meant.

>> It's working on develop branch for me with my mingw-w64, but it's not
>> for you with your version. Problems like these are exactly why I don't
>> support mingw. People ought to use MSVC or winclang on Windows, those
>> work much more reliably. If people really need a POSIX-y environment,
>> Windows can now run Linux binaries very well, even from Win32.
> 
> Your decision to simply refuse to support some platform, well.., bothers
> me. I understand that you do not have access to different compier/platform
> versions, and that makes looking for bugs quite a burden. But it was my
> understanding that this is how library maintainance works in Boost. You
> have the test matrix, where people offer to test your library on
> compilers/platforms you have never thought of, and you get the required
> feedback. Can you be persuaded to a conditional agreement: if Outcome gets
> accepted into Boost, you extend the range of supported compilers.

It costs time and money to support platforms you don't personally use,
and I have found an eager approach to deprecating and desupporting open
source code I no longer personally use to be the only viable approach
for my very limited free time. Once you're been supplying open source to
people for twenty years as I have, it's the only feasible attitude to
take. It also lets end users either move on to alternatives instead of
being strung along waiting for fixes to software I won't be regularly
updating any more, or else employ me to fix things for them if their
need is urgent.

I aim to support the most common 98% of users in my open source. If
others wish to maintain my code on their niche
platform/compiler/architecture, I will accept patches from them
maintaining that support, and I'll try not to gratuitously break their
contributed code. But I won't be doing it myself. I think supporting the
top 98% of the most common environments is more than plenty.

And I would add that Boost libraries only need to demonstrate a
portability requirement. That falls very far short of endless and
permanent support of niche, and often broken, toolchains.

> Macros other than #include ? Usually you need macros to do things in a
> different way based on platform, but the precompiled heder does not know
> what platform it will be used on, so I wonder what macros you mean.

Quite a bit of code is auto generated using preprocessor
metaprogramming. All the ABI and namespace versioning stuff, for example.

The partial preprocess step executes all the metaprogramming at build
time and I commit to git an expanded edition without the preprocessor
metaprogramming. When you #include Outcome, your compiler only needs to
preprocess platform specific #if branches. It is very little work to do,
and hence runs about a half second quicker.

>> Whilst Outcome is in an unstable state, the actual namespace used is:
>>
>> namespace boost { namespace outcome { inline namespace v1_GITSHA { ... } }
>> }
>>
> 
> This sounds like we are doing a formal review of a library in an unstable
> state.

Ok, unstable ABI then. Right now I am not promising the ABI won't
change. When I do promise that the ABI is written permanently into
stone, you'll get your boost::outcome::v1 namespace, and per commit
it'll be checked for breaking changes by the abi-compliance-checker.

That way end users, who will tend to return outcomes a lot from public
extern functions, will know for a fact that upgrading Outcome does not
force a complete rebuild of all shared libraries.

Niall

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